Ed,

>As someone writing COM servers, especially at a middle tier, I disagree. I see VFP as a very different sort of tool than you might...

I don't think so. I too work with com servers but don't have experienced the problems you've pointed out.

>, and my opinion, with no special inside knowledge or secret back channel details on the product, is that this is where VFP is going to end up in the long run.

Do you think so ? Why ? What alternative do we have for writing OOP front-ends at the moment ? VC++, Delphi, JAVA ? I don't see many people do this in the future.

>I base this on the changes in VFP6 in general, and especially on the features and enhancements added to it in VS SP3. I may be wrong. I don't see it as a tool to solve all problems, or even as the right tool to address all layers of a single application.

Of course not: You won't write a printer driver within VFP. The first layer wich is a candidate for replacement is the Database layer. Bussiness-rules and Front-end will do IMHO.

>I've been using this manner of reselecting tables since I learned FOX. I did wonder why most examples use the (longer) ALIAS() method while in (at least) the cases i've seen this tip would do fine.


>Again, for the way I write code, and for the assumptions that I'm willing to make about the state of the application environment, especially with multiple clients, with different needs and focus using the services of an application, referencing an alias and ensuring that the referenced alias is active and open works better for me. Your method may work for you;

And might for many others.

>I simply point out that it doesn't always work, and in my case, it often would be a bad approach to the problem of restoring the state of the data environment at exit. You probably would take exception with my saving the primary key on entry, and seeking it at exit, rather than saving the record number and doing a GOTO nRecNoAtEntry.

Yep, I Do, unless it concerns a view wich is requeried. And of course you've have to identify which one of the options would fit best. As a programmer you've got to identify wich behaviour is needed, which performance is best (GO is faster than seek, in some tables or view you might not have an index nor primary key)

This also applies to the reselecting table approuch. If the SELECT(0) approach does not solve the problem right, you might look for another solution. I'll bet you've got exceptions on the ALIAS() method too. It's like using the right tool for the right job.

>Walter, lets leave it at it doesn't work for me, I've tried it both ways, and I strongly prefer the approach I take. YMMV.

I agree.

Walter,