Plateforme Level Extreme
Abonnement
Profil corporatif
Produits & Services
Support
Légal
English
SQLEXEC and Shared Connection Problems
Message
 
 
À
Tous
Information générale
Forum:
Visual FoxPro
Catégorie:
Base de données, Tables, Vues, Index et syntaxe SQL
Titre:
SQLEXEC and Shared Connection Problems
Versions des environnements
Visual FoxPro:
VFP 8
OS:
Windows XP SP1
Database:
MS SQL Server
Divers
Thread ID:
00960314
Message ID:
00960314
Vues:
72
Hi,

I'm having a little difficulty determining the busyness of a shared connection when using a combination of remote views and cursors created via SQLEXEC calls.

The problem seems to be that whenever I check the busyness of the connection using the statement handle returned from the SQLCONNECT command it always returns .F. when it should return .T.

Say we have a connection set up as follows ;

CREATE CONNECTION Connection1 CONNSTRING 'driver=SQL SERVER;server=(local);uid=SA;pwd=SA;database=MyDataBase'

And a remote view set up in the following way ;

CREATE SQL VIEW MyRemoteView REMOTE CONNECTION Connection1 SHARE AS SELECT * FROM SOMEBIGTABLE
DBSETPROP('MyRemoteView','View','AllowsimultaneousFetch',.T.)
DBSETPROP('MyRemoteView','View','Fetchasneeded', .F.)
DBSETPROP('MyRemoteView','View','Fetchsize', 100)
DBSETPROP('MyRemoteView', 'View', 'ShareConnection', .T.)

IF I run my view and after the first 100 records are returned, then test the busyness of the connection it works fine. ie

USE MyRemoteView
llBusy = SQLGETPROP(CURSORGETPROP('ConnectHandle'), "ConnectBusy")

The the llBusy variable equates to TRUE.

Now if I attempt to open the above remote view and then create a statement handle via a call to SQLCONNECT the busy status doesn't behave itself... ie

USE MyRemoteView && begin to download the large recordset
* now get a handle onto the shared connection
lnhandle=SQLCONNECT('Connection1',.T.)
* test to see if the shared connection is busy, it should be!
llBusy = SQLGETPROP(lnhandle,"ConnectBusy")

The llBusy returns FALSE

My understanding is that the statement handle returned from the SQLCONNECT command is using the shared 'Connection1' connection. The SQLCONNECT command should be using a previously shared connection as I've set the second parameter on the SQLCONNECT to true.

Any body got any ideas?

Thanks, Bernard
Suivant
Répondre
Fil
Voir

Click here to load this message in the networking platform