FMP crash when viewing large ESS (SQL) data via ODBC.
Operating system version
Mac OS X 10.6.8
Description of the issue
I have an ESS (external sql data source) defined for an Oracle back-end data warehouse using the Actual Technology driver. All connections work fine. When I change to a layout with the ESS data, FMP will crash.
Steps to reproduce the problem
1. Open FMP data file. This defaults to a "local" data table.
2. Switch to a layout with ESS data.
3. Password prompt immediately appears.
4. Type in password.
I expect the layout with ESS data to be displayed and then be able to change between records.
FMP crashes shortly after entering the password.
Exact text of any error message(s) that appear
FileMaker Pro Advanced quit unexpectedly.
Click reopen to open the application again. Click Report to see more detailed information and send a report to Apple.
A. Goto Manage Database, and select one of the ESS tables.
B. Click sync, select the key field(s).
C. Exit out of Manage Database screen.
D. Go to any ESS layout.
Workaround 2: create a script that does the following:
A. Freeze Window
B. Goto Layout [any ESS layout]
C. Go to Record/Request/Page [First]
D. Go to Record/Request/Page [Next]
Layout works as expected after script finishes and refreshes the window. Trigger this script before navigating directly to an ESS layout each time you reopen the FMP file. You many then navigate to other ESS layouts afterward.
A. Create a "dummy" ESS table occurrence in the relationships graph, but delete all fields except the key field.
B. Exit the Manage Relationship screen.
C. Create a new layout with the dummy table occurrence as the data source (only has one field).
Access this ESS layout before using any other ESS layout each time you reopen the FMP file. You may then access any other ESS layout afterward without problems.
I believe this demonstrates there is some sort of buffer or timing issue when FMP makes the initial connection to the external data. FMP crashes if it is on an active layout and the data is too big during the initial connection. Subsequent connections don't have this problem.