Yes, SQL is a must for US too. We already implemented INSERT INTO, CREATE TABLE and we are working in SELECT SQL.

So SELECT SQL will come with the product, and it is not that hard to build it ;-)

>>
>>>Since Microsoft doesn't seem to care much about the "VFP way of doing things", it has (maybe unintentionally) unleashed a number of private, non-MS development teams to take the VFP concepts and run with them. Companies like eTecnologia are actually adding new sorely needed features to the language and doing away with previous limitations, while they are at it (to name just one: no more 2 GB DBF -file limit -- which was probably arbitrary to begin with, left in place in order to steer people towards SQL server...).
>>
>>No, it was not arbitrary (in the meaning of "on a whim") as vfp's "phantom" locking needs the other half of a 4 byte max sized file - which for instance is also the max file size on FAT32, which came much later than vfp's schema of record locking.
>
>How soon do we forget the good old days when to be FAT32 was enough. Or not. Thanks for reminding me of that particular pain...
>
>>
>>>I have a strong feeling that VFP is simply not going to to away, because there is simply too much value in the datacentric, OOP, almost fully metadata -driven, local cursor processing approach to be thrown away.
>>
>>The thing worrying me is that I here almost nothing about implementing SQL - which in itself is ton-trivial task. The ability the reprocess cursors again with SQL and xBase was the thing where vfp's approach was "better" than the approaches used in .Net 2.0, where you had to work harder for the same results.
>>
>
>As I understand it (and eTecnologia people can and probably will pipe in here), SQL -capabilities are right around the corner. It is a critical piece of the puzzle, agreed.
>
>>>Of course a VFP -derivative language is not an end-all do-all one-size-fits-all -solution, but it is a great power tool in a programmer's toolbox when one has to quickly prototype an application and/or write one that needs to slice and dice through data quickly and effortlessly.
>>
>>Not arguing about the power, but it is also double edged as it is sooo easy to fall into bad habits<g>.
>>The thing "going" for xBase is data integration - thy dynamism can be found in similar levels in most scripting languages, from my other favorite, python, over ruby to javascript, groovy and PHP. SQL was the thing seting VFP apart from the other xBases: you could talk to your intermediate layer in nearly the same language as a C/S backend.
>>
>>I do hope both GUINEU and Etecnologica can finish their products...
>
>From what I see (at least as far as eTecnologia is concerned), they are making huge progress, almost daily. It will still take time, and who knows what evils lurk in the darker corners of the various technologies involved, but as it is right now, you actually CAN build a VFP form or even an app, turn it into .NET Windows app, and start using it.
>
>And you are certainly right about bad habits. The new tools will allow you to mend your bad dBase ways, though, by allowing you to force strong typing, for example, if you are so inclined, or not, if you are so declined :0]
>
>As I said, the main thing for me is to have at least some hope that my trusty old VFP power tool may be able to stay in my arsenal as the right tool for the right job, after all. I am by no means implying that it would trump everything else in every situation.
>
>
>Pertti
>
>>
>>regards
>>
>>thomas