Filemaker 9 and MySQL shadow tables.

[TomOfSweden]

:( Has anyone worked with SQL shadow tables?

After developing a solution with SQL how do you move it to the production environment?

We have developed a solution using shadow tables to an SQL Data source. Now we are ready to move the solution from the development environment to production. When we reconfigure the DSN in the ODBC administrator nothing changes in Filemaker. The shadow tables remain connected to the old DSN. Any attempts to reconnect the shadow table data source causes everything to mix up and tons of work is lost. We have tried every work around we could think of and it looks like we have to rebuild the Filemaker database for the new environment.

One other main issue is that it seems impossible to change the Database Name of a shadow-table connection.

Eg, we want to change the shadowtableconnection:

MyOwnDSN.database_name_old.tableoccurrence1

TO:

MyNewDSN.database_name_new.tableoccurrence1

The two different tables have the Exact same layout, but is located on different locations and under different database-names.

How do you move the connection from A to B?

Is it even possible?

My concern goes to all solutions built with shadow tables, which sooner or later may have to move, maybe from one service-provider to another. If the service provider then has preset database-names, this will ruin the whole Filemaker solution.

This can't be possible that you can't move a solution like this after development.

[DannyDK]

If you change the DSN to point to a new database, any FileMaker data sources using that DSN should automatically point to the new database server. The database names do not have to be the same, but the structure (table names, column names and order, etc.) in use by FileMaker will have to be the same for it to work.

If you create a new DSN, then you will need to change the data source in FileMaker to use the DSN. This works fine too, but again, the structure will have to be the same.

I have tested both methods and they worked for me.

The former is probably the better practice. You can have FileMaker point to a fixed DSN name and change the specific DSN entry in the ODBC administrator (rather than creating a new one) when you want to switch between databases. In this way, you can have a single database that points to different external databases when used on different machines, assuming any stored user credentials are the same.