1. The new table structure introduced for .map projects in 11 cannot be read by builds prior to 11. That means .map projects created by 11 are not backwards compatible to prior builds of Radian, Future or Viewer.
2. Tables created in projects prior to 11 remain in "pre-11" form even when opened by 11 and have the limitations of pre-11 builds, namely a limitation of 2 billion variable length values. If you create a project in, say, .10, save it, and then open it in .11, all the tables in that project remain in .10 form. If you just modify one of the tables and then save the project, the table remains in pre-11 form because the table itself, edited though it may be, was still originally created before 11.
3. Any new tables created in the project by .11 or greater will be in 11 form. Given point 2 above, you could have a project with tables created in .10. Open the project in .11. Copy one of the tables and paste it. You've just created a new table in .11. That new table that you've pasted is in .11 form. All of the other tables, including the original you copied, remain in .10 form.
We strongly recommend that anybody working with 11 and newer take a moment to migrate their projects into 11 form.
The easiest way to do this is to open a project in 11 and then choose File - Export Project and export it to .map format. That creates an 11 .map in which all of the tables are in 11 form. Doing this avoids the messy situation of copy/pasting tables within a project where some can be in 11 form and others not.
If you prefer, you could also export the project to MXB format. When you open the MXB all of the tables also will automatically be in 11 form. Since MXB is new to 11, exporting projects to MXB is one way to ensure that users of those projects (for example, people who have downloaded Viewer) are forced to move to 11 or more recent Future and Future Viewer builds. We probably will change all of the projects made available as downloads on the Manifold web site into MXB form for just that reason.
We realize all the above is an inconvenience. But that's life in the fast lane with an open beta process. The modification to tables to go to 11 and further removes a limit that was in prior releases but very rarely encountered. It is the root cause of the crash reported by StanNWT (thank you Stan!).
That there is a limit to what can be stored in a table in a .map file is OK, since all products have some limits. That exceeding that limit caused a crash is a bug, plain and simple, since exceeding limits should pop open a routine message and not cause a crash.
I think in some ways it would have been perfectly acceptable to simply alter the product to prevent a crash and to pop open an error message when the limit was exceeded. Instead, we decided to do that but also in addition to remove the limit. Or, more accurately, to condense all such limits down to a single limit of 2 billion records per table within a .map file.
2 billion records at the present time is the limit for the number of records in any one table stored within a .map file. It's not a project limit: you could have 200 tables, each with up to 2 billion records, stored in a .map file.
It's also not a Manifold limit. If you have an Oracle or PostgreSQL database with 10 billion records Manifold is happy to work with them. If you do a transform that takes a table with 10 billion records in Oracle and you want to add 50 billion records resulting from that transform to another table in Oracle or in PostgreSQL or whatever, no problem. You can do that as well. It's just that for now the limit to the number of records in a single table stored within a .map file is 2 billion.
Eventually, that will be dialed up to some larger value but for the next few months or so 2 billion records per table seems to be enough. :-)