Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
File DSN in Cursoradapter Builder
Message
General information
Forum:
Visual FoxPro
Category:
Client/server
Environment versions
Visual FoxPro:
VFP 9
OS:
Windows XP SP2
Network:
Windows XP
Database:
Visual FoxPro
Miscellaneous
Thread ID:
00985862
Message ID:
00991166
Views:
17
All my CAs use the same shared connection. I also do not close any connection when I close a form. I create 1 connection at app startup and use that connection throughout the app session. I close the connection when the user quits the app.

If you close a connection when you close a form, then each form has to be using its own connection. Otherwise, if you have multiple forms open that use the same shared connection then close one of them, the other forms have just lost their connection and any data changes will be lost. Each form can have its own connection. You just have to call your connection manager before the form DE tries to open your cursors. You manager then has to create a new connection for that form, and return that handle. You can eat up numerous connection handles doing it this way, and is probably not a very good way to do this.

>Belated thanks... that works well. Do you maintain any sort of mechanism for closing open connections when adapters are destroyed, in order to keep them from accumulating? I tried to do that by modifing my adapter class to store the handle assigned returned form my connection manager in a custom property (odbchandle), and then calling SQLDISCONNECT(This.odbchandle) in its AfterCursorClose event. A look at the open connections in my back end database (Firebird) confirms this does release the connection when the containing form is released. However, but the next time I try to run that form, or any other other containing that same adapter, I receive a 1466 ("invalid connection handle)" error in the adapter's AfterCursorFill. It seems that that =gethandle() isn't honored when the form and its adapter are instantiated a second time. DISPLAY OBJECTS verifies that both were released the first time. Maybe something is getting cached somewhere....
Mark McCasland
Midlothian, TX USA
Previous
Next
Reply
Map
View

Click here to load this message in the networking platform