I've done a ton of searching of the web, A5 wiki, and the help docs on most, if not all of the following aspects that follow and am quite frustrated at the moment.
After carefully pulling all of the tables from multiple back-end .accdb files, ensuring the indexes, field types, etc. were correct I wrote a series of routines to add/delete fields and tables then rename each field and table to 10 characters or less. I did not rename any indexes at that time.
I created a new A5 DBF database using the access data. I was a bit surprised to see that one of the indexes came over with the data. Also many of the field sizes seem way off for the type of data converted. I then tried exporting one of the tables from access into a DBF file directly. Not only did the index not come over but the Access auto-increment field came over as an 'ExponentNumeric' field type which there appears to be very limited info on other than posts here saying "don't use them".
*** Any info available on when, why, and how the 'ExponentNumeric' "non-data-type" is used or should be avoided.
So I'm currently going through each table in the "from Access" conversion analyzing each field, changing length and decimals where it appears necessary and manually setting up rules and indexes. To say the least I'm finding my 'Into to A5' frustrating and tedious.
*** Is there a better way to import from Access that would make this process smoother? To bring in the indexes and set the auot-increment rules automatically?
For all of the advertising A5 does to promote moving from Access to A5 I've found little documentation describing a recommended conversion process, data type equivalents, or any pitfalls to watch out for.
*** Are there any resources I've missed?
My development plans are to move first to a desktop version where the DBFs are shared on the local network, then create the same using SQL Server (company std not mine), and finally to the Web with SQL.
Any help, opinions or links in making this a more pleasant trip would be appreciated!
- Bob
After carefully pulling all of the tables from multiple back-end .accdb files, ensuring the indexes, field types, etc. were correct I wrote a series of routines to add/delete fields and tables then rename each field and table to 10 characters or less. I did not rename any indexes at that time.
I created a new A5 DBF database using the access data. I was a bit surprised to see that one of the indexes came over with the data. Also many of the field sizes seem way off for the type of data converted. I then tried exporting one of the tables from access into a DBF file directly. Not only did the index not come over but the Access auto-increment field came over as an 'ExponentNumeric' field type which there appears to be very limited info on other than posts here saying "don't use them".
*** Any info available on when, why, and how the 'ExponentNumeric' "non-data-type" is used or should be avoided.
So I'm currently going through each table in the "from Access" conversion analyzing each field, changing length and decimals where it appears necessary and manually setting up rules and indexes. To say the least I'm finding my 'Into to A5' frustrating and tedious.
*** Is there a better way to import from Access that would make this process smoother? To bring in the indexes and set the auot-increment rules automatically?
For all of the advertising A5 does to promote moving from Access to A5 I've found little documentation describing a recommended conversion process, data type equivalents, or any pitfalls to watch out for.
*** Are there any resources I've missed?
My development plans are to move first to a desktop version where the DBFs are shared on the local network, then create the same using SQL Server (company std not mine), and finally to the Web with SQL.
Any help, opinions or links in making this a more pleasant trip would be appreciated!
- Bob
Comment