You cannot use vbscript  for server-side scripting in SPS 2003. You could use
VB.Net (close in syntax to vbscript) to create a web  part or use VB.Net script
in a custom aspx page under the _layouts folder. You can also do client-side
vbscript in a Content Editor web part  if that will work for your application.

The application pulls from a few tables in a databsae and displays a
calendar of events. I would like to use the data view web  part but have
found that they are limitied to only pulling from one datasource/table
at a time. This is too bad............

When you say create a custom aspx page under the _layouts folder do you
then mean to put  that page in a content  web part?

I mean to new .aspx file in http://servername/_layouts/ (the location of all the
templates, etc) - you could then display this in a Page Viewer part  if you like.
Normal page locations can't use server script, but pages located here can.

You could also write a web  service to pull the SQL data together and have a data
view contact that, or if the tables are all in the same DB use a custom query or
stored procedure...

This will sound stupid but where is the _layouts folder? I can't find it
from front page.

All the tables are in the same database. So we can use a custom
query with the datview web  part?



Just curious though could you send me in the right direction for
creating a web service?

There are a ton of online resources on the basics of creating web  services. The
SharePoint SDK document documents the web services delivered with SharePoint for
some examples. If I remember correctly, you are not a developer, and this is
very much a development task. I'd suggest you go the custom query (set in the
data view web part  properties) or stored procedure (created in the database, and
retrieved via a simpler custom query - better performance) route.

Ok. Your right I am not a developer, but we do have one available to us.
Thanks for your suggestions as they make a lot of sense. It is probably
better for us to go the stored procedure or custom query route.

So, stored procedure perform better then custom query?

In general, yes. A stored procedure is a SQL query that is created, stored, and
cached inside the database. Depending on the complexity of the query, the perf
gains will be anywhere from none to considerable, but it should never be slower.
In addition it allows you to tweak the query centrally, so that if you have
multiple copies of the web  part and the query chages you don't have to change
every instance of the web part.