CajunCenturion
Programmer
I am converting a number of FoxPro tables to SQL Server 2008 using the OpenRowSet function. The original tables didn't have key fields defined as identities, and some of them have duplicate values. As expected, the insert command bombs on those; however, when I remove the duplicates from the source table and rerun the insert, it bombs on the exact same records. This leads me to believe that the OpenRowSet runs its select against a cached table - created during the initial run - rather than the original source table each time. I have tried FreeProcCache and DropCleanBuffers to no avail. I have restarted both the workstation and the database server, but again, to no avail. However, leaving the computers up overnight fixes the problem. This further suggests that a cache is created and exits within the database; however, with an expiration time. I would appreciate any information on how to manage this cache, if that's truly what it is.
Here is some sample code:
The command is being executed from a stored procedure, and again, the command works fine on its first run. It just doesn't honor changes made in the source table for subsequent runs. For what it's worth, I am doing this from SQL Server Management Studio logged in as the administrator.
I know some of you will suggest alternate ways of accomplishing this task, and while I make take advantage of that down the road, right now my priority is to resolve these cache management issues.
Thanks.
--------------
Good Luck
To get the most from your Tek-Tips experience, please read
FAQ181-2886
Wise men speak because they have something to say, fools because they have to say something. - Plato
Here is some sample code:
Code:
SET IDENTITY_INSERT [schema].dbo.[table] ON
INSERT INTO [schema].[dbo].[table] (<field list>)
SELECT <field list> FROM OPENROWSET('VFPOLEDB','<path>';'';'DELETED=YES', 'SELECT * FROM table WHERE NOT DELETED()')
The command is being executed from a stored procedure, and again, the command works fine on its first run. It just doesn't honor changes made in the source table for subsequent runs. For what it's worth, I am doing this from SQL Server Management Studio logged in as the administrator.
I know some of you will suggest alternate ways of accomplishing this task, and while I make take advantage of that down the road, right now my priority is to resolve these cache management issues.
Thanks.
--------------
Good Luck
To get the most from your Tek-Tips experience, please read
FAQ181-2886
Wise men speak because they have something to say, fools because they have to say something. - Plato