>Hi Vin,
>
>>Well, I'd hardly call it "jimmying connections" -- it's a pretty well-accepted approach to database access.
>
>I'm curious about your approach. Do you pull the local dataset down as an Offline View and then knit it back together as a batch process or what?
>
>Hugh

Hey Hugh. I use the disconnected approach when I am working with ADO objects and unbound data -- which is most of what I do these days whether it's in VFP or VB. In other words, I rarely use remote views in VFP, which is why I included the caveat that the ability to use a disconnected recordset approach will depend on your overall architecture. I am not sure of the original poster's application approach, but my point was mainly that the frequently referred-to MSDE limit on concurrent "users" is not the same as what we sometimes think... [see my rambling at the end of this post for more on this.*]

But, to the point! You asked about the disconnected data approach. Well, in VFP business classes, I tend to deal with data objects the same way as I would in VB -- except that I can dump the data into a cursor for quicker middle layer access. In other words, to get data out of the database: make a connection to the database; grab the data you need; disconnect from the database; manipulate the data as necessary; pass the data on. To get data in... construct INSERT or UPDATE statements, or, better yet, calls to Stored Procedures that will do that for you; connect to the database; execute the statements; disconnect; pass on any errors, etc.

Of course, that description assumes VFP as a middle layer... in regards to VFP GUI access to the data, it's actually been about two years since I worked with VFP forms (which I miss). But, basically, using an unbound data approach would be the key to it... grab the data according to my mid-layer rules above, or even call the middle-layer object itself; at that point, you could store the data to variables and use these as the control source, or run through the recordset and explicitly fill in the values, or, you could even convert the data to a cursor and bind to the cursor (which I guess is your "offline view" approach above).

All of this has presupposed that you are using ADO connection, command, and/or recordset objects. I think you could also do the same with SQL Pass-Through, choosing to close the connection each time. I am not sure of the overhead for SPT -- for ADO, the overhead of closing the connection each time is much less than I feared, and has not once been a bottleneck -- though some good coding principles help... specifically, tak care of all related database calls in one fell swoop: gather all the statements you need before opening the connection, then open in, then execute them all, then close it. This way, you are not opening and closing connections inside of a large loop, etc.

Hope this helps.

Vin


* [Regarding the 5-concurrent "user" approach.... In fact, Microsoft's own website refers to MSDE's 5-concurrent *batch* limit. Several other sites talk of MSDE's concurrent "user" limitation, but I have not found any reference to an MSDE concurrent *user* limit from MS itself (although maybe someone else has). I think this is simply a common misquote of the real limit. And, this is not just a matter of semantics! The MS documentation seems to realize that a database connection or batch does NOT equal the standard definition of application "user." But it seems like this concurrent *batch* limits gets misquoted frequently....]