Thomas some answers below:


Samuel,

from your company site:
# Table size limit of 16 Exabytes. The engine is 64 bits capable, so the maximum table size is 264 - 1. This is nearly 4,000,000,000 times bigger than the actual limit.
# More than 255 fields by table.


Question.
I interpret this as table size in bytes and number of fields. What I miss is a statement on the maximum number of records in the enhanced tables: vfp's limit of 1 billion is in reality cut down by the 2 Gig border to something on the order of 10 to 50 million records and sometimes I need to vertically split tables to reach even that number - which is one of my worst gripes with vfp.

Answer.
We are sure that the maximum size of the tables can be in the 64 bits range (exabytes).
Increasing the RecCount over 4 bytes (32 bits) will mean some changes to the Header and CDX format, the CDX format allows some kind of extension for record numbers bigger than 4 bytes.

The header actually has some unused info that we plan to use the moment you have more than 4 billion records in the table.

So the way it will work is:

Your record count < 4 billion (4 bytes needed for reccount). Table info completely compatible with VFP, beyond that it will lose compatibility.


Question.
Using 8-byte record pointers probably needs a much larger effort (new cdx format, different header) than just rasing the 2 Gig table size limit - any statements to that topic ? Don't get me wrong, for *me* just raising the usable Reccount() 50 times alone would make a purchase / upgrade at typical vfp cost a no-brainer if it was a vfp update.

Answer.
Also the Memo size will need an upgrade to be 8 bytes length instead of the current limit of 4 bytes. The Memo Header also allows for extensions for this. We are aware of this, but we are also considering get rid of a limitation of the FPT format: it grows excessively when you replace old info. Getting rid of this will mean a more complex header format, that the simple actual header.



The big questions for are:
Question:
1) the stability of the new system - we are well aware of vfp's warts, but it *is* a very stable product where I don't have to verify every result.

Answer.
Data integrity is top in our list of features. Actually it is very stable but we need a lot of testing before going into beta.


2) how code compatible is the new system ? Learning the slight differences is another type of cost - in the same league as the cost of splitting tables. These costs are less visible than a purchase price, but can be markedly larger...

I have compiled a lot of code without a single change. Thats is our target and we are really, really confident this is feasible. On of the first tests I did was to recompile the implementation of sys(2015) that is available in the Download ID 9704, and we could with no change. If you look at the code it is somewhat complex. Of course We did some optimizations after that, because like I wrote you before, accessing m.aVar is a lot faster than accessing just aVar (because the latter could be a field).

Try the online compiler at www.etecnologia.net/onlinecompiler/ the february update is a lot closer to our dream of Full Recompile without a change. As long you use the available commands and functions it will compile almost all VFP code and more important it will perform faster and still keeping the functionality.

Other things I have compiled is a library of statistical functions (remember Z, t Student, F Fisher, Chi Square) implemented in VFP and now compiled to .NET without a change, thats a pretty good sample of Mathematical handling for the compiler.

So to the moment we are still confident we can achieve Full Recompile to .NET without a change.




Regards

Samuel