Thanks Bob (grinning) though for what I'm not exactly sure!

This MTS sounds like its "not ready for prime time" to me.

ADO sounds even worse, and worse yet is the impression I've been given here that ADO is to be THE ANSWER to all woes. If its strength is datasheets and such, and it essentially paralyzes database fucntionality, then we may be being sold another BILL of goods (pun intended)!

Instead of getting better, things definitely sound more grim. But hey - it's all for out own good in the end.

Thanks again (yeah, right!)

Jim N

>>----- SNIP
>>>
>>>THis will not work with MTS because the object created as ox disappears after each method call! Your reference does not disappear, but MTS might reuse the object so if another user created the same object after you your call to nextrecord might get THEIR next record! You can make no assumptions about the state of an object between method calls while it is part of MTS.
>>---- End Snip
>>
>>Bob,
>>
>>Since the formal announcement of VFP 6, anything with the letters MTS in it piques my interest.
>>So it was that I came across a R. Strahl article (on his page) that went into some detail about VFP6 and MTS generally.
>>Quoting some from there: "Apartment model threading makes it possible. . . Each apartment is guaranteed to get called from the same thread context that created the server in order to provide a thread-safe. . .".
>>
>>I find this to be at odds with your quote above. It is no doubt because of the plethora of confusing and related terminologies surrounding the issue, but could you be kind enough to take a stab at explaining it so that it makes some sense to the more casual reader?? It would certainly be much appreciated, cuase right now I feel like all I get is contradiction on issues like this and ActiveX/COM and a few other things.
>>
>>Thank,
>>
>>Jim N
>
>
>I don't think this issue is related to the threading model. Essentially, when servers become part of MTS the createobject call is redirected and objects are only created on an as needed basis.
>
>If you are using MTS your business servers must be very consise. In fact, you should not even use property assignments. For instance
>ox = createobject('mtserver.invoices')
>ox.discount = 10
>y = ox.discount && returns 9, or 10 or 12.
>the above assignment to y does not necessarily return what you said ox.discount to. MTS might have decided to use your ox object for something else and you go a different object to return to you its discount property. So if you want to pass the discount to the object for calculation, it must be done as a parameter to the method. These objects are really really stateless. Every assignment, every method call could be to a 'different' MTS object in the object pool. You must program accordingly.
>
>What is ADO to me? Take a shotgun and blow a hole in VFP's head and you have ADO. Actually, ADO is a great idea if you spend your days accessing data in spreadsheets and text files etc. I prefer to use a database. I use VFP with SQL Server. ADO does that too. It uses ODBC. VFP also uses ODBC. So now if we could just get VFP to use ADO (so it could do the ODBC instead of VFP doing it directly) we would get to:
>
>1. retrieve strings of data that we could then parse into a cursor we would have to define.
>2. not have indexes available on the ado data.
>3. not be able to use the tableupdate or tablerevert command on the ado object.
>4. Finally be reduced to the level of VB programmers trying to work with database files.
>
>So we should be excited about ADO because we can let it use ODBC instead of us using it directly via remote views? This is progress? Of course, I know that most of us need to read excel databases and word databases all the time and we've just being dying for ADO to save us.