Information générale
Titre:
Breaking the link between a cursor and its source table
To All,
My group's been working with SQL Pass through for years now, but we've just discovered that the "cursor" that's returned by
SQLEXEC(, "SELECT * FROM MyDB.dbo.MyTable", "MyResultSet")
is actually a view of the backend table.
We'd always assumed that the cursor was a read-write VFP cursor. When we started doing UPDATEs and REPLACEs against the return cursors, we found that the record-level buffer was staying dirty (not commiting the data to the table) until the record pointer was moved or a TABLEUPDATE() was isssued against the cursor.
We *really* need the cursor to be a VFP read-write cursor with no attachments to the backend.
Our current solution is to do a SQL query with a dummy field into a local cursor and then drop the dummy field:
SELECT *, .F. AS ForceLocal ;
FROM MyResultSet ;
INTO CURSOR MyRealResultSet READWRITE
ALTER TABLE MyRealResultSet ;
DROP COLUMN ForceLocal
While this works, its an extremely expensive solution: instead of one disk write, there are three:
One to get the result set via the SQLEXEC()
One to force the result set to be a VFP cursor (adding the dummy column)
One to drop the dummy column.
I really want to be able to get a local VFP cursor from a SQL pass through call with only one disk write.
Is there any way I can get ODBC to write the result set as an unbuffered VFP cursor?
Regards,
Thom C.
Suivant
Répondre
Voir le fil de ce thread
Voir le fil de ce thread à partir de ce message seulement
Voir tous les messages de ce thread
Voir tous les messages de ce thread à partir de ce message seulement