Hi again, Walter

>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 ??
>

Multiple variables pointing to the same form, or anything else for that matter, doesn't really matter at all in this - release what I say to release, no more and no less (is the preferred method for me). IF I happen to refer to such variables AFTER I have released the form object, then an error should be raised that I am referencing something that is not there. Of course I would be free, at any time, to release any and all of those variables without raising an error.
By the way, I don't see setting a variable to NULL as "releasing" that variable - only changing its content.


>>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.
>
Yes, I agree. I only argue that RELEASE should do exactly the same thing (you said differently earlier).

>>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.
>

Maybe worth a new thread, but I feel that it would be wasted without there being a "Wish Discussion" category. To me this one, especially, would require lots of dialogue and ideas before a practical wish submission could be developed. To me a "Wish Discussion" category is the only reasonable place for this. The editable wish thing recently delivered on UT is too far out of the way and is not conducive to "dialogue".

>>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.
>

This is something genuinely UNKNOWN to you and me. For instance, we hear a lot about the old FP legacy code and its being a burden in VFP. Well, at one point FP was scheduled to have a C/S capability. Who can say that much of that code is not already inside the product??? Who can say if possibly some of that code has been used in delivering what we have today with views, etc???

>>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.
>

It is not only difficult, but also subject to required detailed revision whenever a table format or field format might be changed.

>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..
>

Yes, exactly, and what I also want is to do this implicitly by SQL (or xBase command) rather than explicitly.

>>Hope this explains better,
>
>Yep it did.
>
>Walter,

Cheers Walter,

Jim N