Jim,

sorry I accidental pushed the send button in the previous reply.

>Well first let me point out that the RELEASE of an array releases the memory occupied by that array, not just the memvar name referenceability. I see the object reference as exactly the same thing. Now if only the variable is released then I have no way of knowing/referencing the object later to release it.

Hmmm... What about multiple variables pointing to the same form ? If a variable is released, should it also release all other variables or set them to .NULL.. How should I release only one variable of say about 3 referencing the same object, without releasing the object ??

>Secondly, the documentation (in its four meagre lines) specifies RELEASE, not the Release() method. And the concept of an object releasing itself has always been a bit strange to me - get rid of me as I run is like suicide to me. Just doesn't make sense in my little head.

I think this is a matter of taste. I'm very comfortable with the release method. From an OO standpoint it seems reasonable to use the release method.

>On the VFP-to_VFP thing earlier. . .

>I want to be able, in the native VFP language, to have a SQL statement processed by another workstation and have the result-set returned to the issuing (of the SQL statement) workstation as a normal and regular cursor( or perform any updates or deletes, depending on the SQL statement issued). A VFP-Server, if you will, talking with VFP clients. No ADO, no ODBC, no SQL-passthrough, no anything fancy. Sure, maybe some new SET command or two, and/or maybe some new clause(s) for USE command, but that's about it.

This standpoint definitely makes sence. < G > But this is whole new topic. In short: you want some Client-server capability which is wholy transparent trough the language. I think there is a lot to say about this, maybe this is worth a new thread.

>I even believe that regular VFP (xBase) table manipulation commands could operate the same way. For instance, workstation issues a COUNT FOR... and VFP "knows" that the table in question is accessed by the 'server' running elsewhere and runs actual command there, returning result to expected area.

I know this kind of thing is very difficult to implement and VFP being native Client/server would probaply mean a great deal rewrite of the product. But you're right this definitely would mean a great and big step forward.

>At the very least I would like to see this for SQL. Then, at least, we would have a chance to create n-tier applications which continue to use the VFP engine.

>Presently, n-tier means that we lose our beloved (fast and simple) VFP engine. What's the point of using VFP at all if we cannot use it's best feature???

We don't lose de VFP engine, but need a little middleware to let the two tiers communicate. Presently, this piece of middleware has to be managed by the programmer. Your proposal is to let VFP handle the middleware hidden for the developer (and even a step further). This I like very much, because building good middleware is difficult and timeconsuming for most developers.

At the very least VFP should be able to pass cursors and views from one to another tier in a very transparent way, without XML, ADO, OLE DB etc..

>Hope this explains better,

Yep it did.

Walter,