Hi Samuel,

>Are you a wizard? :-)

Well, I sometimes work for a company called "Wizards&Builders" and style myself as the part time resident demon shaking up the wizards
- if you go for old music jokes.

>You are actually right, the 32 bits limits is related to the usual function used for Locking and Seek. But in Linux and Windows there are counterparts of these functions with 64 bits. So what happens when you rise the limit to 64 bits?, you get exabytes.

As you work for the developing company, a few hints from a very interested potential customer:

- your example code links don't work for me (W2K, Firefox >> 404...)
- Are you planning to support vfp functions as well (your site literally speaks only about "command coberage")
- please publish a list of vfp commands/functions already supported/partially supported/planned/not planned
- make a similar separate list for SQL compatibility with vfp (especially when using the exabyte layer <bg>)
- how about ball park figures for intended price range, licensing model and release targets with disclaimer ?

- get more technical in your desription, as I don't have a clear picture of the intended architecture<g> 

    - are table layers similar to the replacable drivers for clipper, and vfp runtime is just a layer?
    - if so, how can you run on the compact framework ? Are the runtimes needed there as well?
    - Do you have to implement (and test) your own SQL parser/engine for the exabyte layer ?
        - Or can you somehow call back from the well tested and to us familiar vfp engine (sys 3054..)
        - Or are you re-Using another already proven ISAM handler (Codebase, Apollo and so on)
    - Will it be possible to use vfp-XSource-tools (for instance import/export wizard) on exabyte layer?

- publishing your benchmark code will be a great way to build trust.
- publishing benchmark code showing areas where performance is the same 
    or even slightly worse could enhance trust even more.
- optional static typing enhancing the speed of some areas might relieve me of the need to code some fll's 
    This sounds a bit like pyrex for python<g>.GREAT!

If you have to implement the engine for the exabyte layer yourself, I'ld try to minimize the danger by working only the largest tables first with your compiler. Would it be possible to run a vfp code from the vfp runtime, branch into your .Net extender and from there call up the any vfp-code compiled with your compiler into .Net assemblies ? This way at first I don't have to veryfy every step, only the things routines working on the exa tables.

This really sounds fascinating - we are currently thinking to move away from dbf to DB2, Postgres or MSSQL mostly for the 2 gig reason later this year. You might give us another option <bg>.

I completely understand the reasons for the disclaimer on your site - perhaps under a similar disclaimer you could tell a bit more about your tool. At least you will get some feedback on what I think is necessary/helpful as soon as I have a clearer picture<bg>.

The only drawback is if this really works I won't go as deep into Ironpython to get some dynamic .Net knowledge as I had planned before.

regards

thomas