DaveMarvin
New member
- Local time
- Today, 09:57
- Joined
- Mar 21, 2012
- Messages
- 6
What elements of a development database may be problematic when deploying an application to run under Access 2010 Runtime on previous versions of Windows?
I am developing a new application using Access 2010. My development machine is running 32-bit Office 2010 on 64-bit Windows 7. My client is still running Office 2003 on their XP machines, and any upgrade in hardware and software will occur after the scheduled delivery date of my application. I've installed the latest version (14.0.6024.1000) of the Access 2010 Runtime (A10RT) on my Win-XP test platform.
In development, I've used the nifty new Navigation Form to organize my elementary forms of the database tables and views (queries). I am able to view the sample contents of all of the tables and views from this navigation form on my development machine. However, when I open the uncompiled ACCDB or compressed and compiled ACCDE on the test platform, the content in some of the elementary forms fails to resolve (I get a blank form). I have been able to "fix" these "broken" forms using a couple of solutions:
1) I've simplified a view query of four tables so that it now references one table and an intermediate view of the other three tables;
2) I've removed "format()" code from a query (a legacy of a previous programming life) and instead adjusted the output format property in the form.
These actions resolved the problems I originally encountered when attempting to view the test db content using the A10RT. After making these adjustments, I was able to view the contents of both forms from the A10RT. However, after I then changed the navigation form format from two horizontal button bars to a top/left button bar configuration, and adding some additional table/view forms to the mix, I'm back to some of the same, and some new, problems on the test platform. Even after reverting to the original navigation form, there are some forms that used to display content that no longer do. I haven't edited any data, or added/deleted/modified any tables or views. Apparently, just changing the default navigation form was enough to change the behavior of the dependent forms in my compiled and uncompiled applications under A10RT.
The multi-table view that is again causing me grief returns 150 records. I have another simple datasheet form that consistently resolves almost 4M rows under A10RT. The test database size is currently at 650MB. It doesn't appear that the problem with resolving the content in certain forms is due to table or database size.
The application is ultimately going to be split, with a "real" SQL database back-end that supports native views and triggers. To that end, I've enabled ANSI-92 SQL Server compatibility and am generating all of my Access "view" queries using ADO (currentproject.Connection.Execute "create view...").
I can probably fix the problems I've encountered in my latest round of testing. What I would prefer to do with my time is avoid these issues as best as possible. What can I do when developing in Access 2010 that I shouldn't do if I'm going to deploy a split DB application that will likely have to run under Access 2010 Runtime on Windows XP platforms?
Cheers!
Dave
I am developing a new application using Access 2010. My development machine is running 32-bit Office 2010 on 64-bit Windows 7. My client is still running Office 2003 on their XP machines, and any upgrade in hardware and software will occur after the scheduled delivery date of my application. I've installed the latest version (14.0.6024.1000) of the Access 2010 Runtime (A10RT) on my Win-XP test platform.
In development, I've used the nifty new Navigation Form to organize my elementary forms of the database tables and views (queries). I am able to view the sample contents of all of the tables and views from this navigation form on my development machine. However, when I open the uncompiled ACCDB or compressed and compiled ACCDE on the test platform, the content in some of the elementary forms fails to resolve (I get a blank form). I have been able to "fix" these "broken" forms using a couple of solutions:
1) I've simplified a view query of four tables so that it now references one table and an intermediate view of the other three tables;
2) I've removed "format()" code from a query (a legacy of a previous programming life) and instead adjusted the output format property in the form.
These actions resolved the problems I originally encountered when attempting to view the test db content using the A10RT. After making these adjustments, I was able to view the contents of both forms from the A10RT. However, after I then changed the navigation form format from two horizontal button bars to a top/left button bar configuration, and adding some additional table/view forms to the mix, I'm back to some of the same, and some new, problems on the test platform. Even after reverting to the original navigation form, there are some forms that used to display content that no longer do. I haven't edited any data, or added/deleted/modified any tables or views. Apparently, just changing the default navigation form was enough to change the behavior of the dependent forms in my compiled and uncompiled applications under A10RT.
The multi-table view that is again causing me grief returns 150 records. I have another simple datasheet form that consistently resolves almost 4M rows under A10RT. The test database size is currently at 650MB. It doesn't appear that the problem with resolving the content in certain forms is due to table or database size.
The application is ultimately going to be split, with a "real" SQL database back-end that supports native views and triggers. To that end, I've enabled ANSI-92 SQL Server compatibility and am generating all of my Access "view" queries using ADO (currentproject.Connection.Execute "create view...").
I can probably fix the problems I've encountered in my latest round of testing. What I would prefer to do with my time is avoid these issues as best as possible. What can I do when developing in Access 2010 that I shouldn't do if I'm going to deploy a split DB application that will likely have to run under Access 2010 Runtime on Windows XP platforms?
Cheers!
Dave
