How do I create a SQL Server 2000 'View' programmatically, using Visual Basic?

September 2, 2008 4:26 AM

I'm working in Visual Basic (Access 2003, technically) with a SQL Server 2000 backend, and I believe I need to create a View dynamically... I am very familiar with creating QueryDef's and Stored Procedures on the fly, but have never attempted to create a View in this manner... My google-fu seems to be failing me at the moment..

Note: The reason I need to create a view in this manner, is that I'm running the same stored procedure many times, with different parameters. By the end of the function, there will be a decent amount of overlapping data, which is unacceptable. I'd like to toss it all into a view as I go, so that I can pull out the distinct records at the end.

If my logic is screwy, feel free to suggest an alternate approach!

posted by Glendale to computers & internet (2 comments total)

"By the end of the function, there will be a decent amount of overlapping data, which is unacceptable."

Your function is throwing the data into a temp table, and you wish to create a view over the temp table? If the temp table's destroyed when the function exists, the data won't be in the view, you understand?

But the basic answer to your question is that you create the view the same way you issue dynamic SQL queries. If you create a dynamic query like this: query( "select 1, 2, 3 from table");

You create a view like this: query( "create view view_name as select 1, 2, 3 from table");
(Assuming your connection has create view permissions.)

Can you more fully explain what you're trying to do?
But if the table isn't a temp table, it's much easier to just create the view in the database once, and just query it.

Is your problem that several runs of your function are logically connected, but are not related to earlier runs? Then use a run-number as a parameter to your function, and stick it in the table.
posted by orthogonality at 5:00 AM on September 2, 2008

Or, as long as you don't have concurrence problems, you can create a temp table that will hold the ids of the records you want to save and make your view something like


"SELECT * FROM myTable WHERE ID IN(SELECT ID FROM myTempTable)"


Your sprocs dump the id of the records you want to see into myTempTable. If there are duplicate records, no big deal.

Definitely hack-ish, but there is a time and a place for a hack. We sometimes use this kind of thing for long running searches.

Of course, you could also pull the data using a sproc, which would allow you to pass a search id parameter from the client:

"SELECT * FROM myTable WHERE WHERE ID IN(SELECT ID FROM myTempTable WHERE SearchID = @SearchID)"


That way, you can keep your searches separate from your coworkers' searches. (With appropriate housekeeping code someplace to delete yesterday's searches). Hackish? Of course.
posted by mrbugsentry at 7:21 AM on September 2, 2008