DSNs, ODBC and "re-pointing" files to a different data source

Questions
1

Latest task has me ready to gouge out my eyeballs if I have to do this again. I'm interested in any useful explanations as to what's going on under the hood and whether there are any ways to make this simpler in the future.

The Task: We spun up a new instance of FM Server 16 to use as a testing platform. A developer we contract with had a development server for their tables in addition to his production server that we access via ODBC/ESS. I set up a new VM server (windows) and set up the needed DSN to connect to their Dev server in place of production. It seemed like a good idea at the time but maybe it was a mistake to use the same exact name and credentials for the DSN that linked to their Dev server?

In any case, with the new DSN set up on the new server, I copied over some back up files and quickly went to some layouts that reference this data and confirmed that I could see data and thus the external data source references TO's, DSN were all working.

BUT......
On closer examination, even though the server had no copy of the original DSN, only the new one The files were still linking to the production server--not the dev server. The only way that I've found to get the files to link to the correct source is to add a totally new External Data Source entry and then go from TO to TO in my relationship graph updating each affected TO to refer to the new data source. Being able to select all TO's with the same data source and give them the same color and being able to see each shadow table on the tables tab with a list of any remaining occurrences helped a lot, but this has been an extremely tedious task and I shudder at the reality that come the passage of time, we'll want to drop in new copies of these files and I'll have to do this update all over again.

Anyone know why the files seemed to "remember" the DSN connection info even when hosted on a totally different server?

Anyone know of any tricks to reduce the pain? (SImply reslecting the DSN for the existing data source didn't work, neither did clicking the "sync" button.)

2 Likes
2

Update:
On further experimentation, it appears that I don't need the new external data reference, but I still have to update each TO to point to a table and that's the most time consuming/error prone part of this process so that's a very minor improvement .

3

I'm unfortunate, just like you, to be aware of this problem for having encountered it in the past.

I think the best we could come up with was to mandate separate credentials for both dev and prod (the dev credentials must not be valid in prod AND vice-versa). If credentials are valid in both environments, the config becomes very "sticky", despite changing everything else. No possible explanation we could come up with.

Anyone who has a different experience about this where the required work is not a pure nightmare is welcome to share.

Are you able to void the dev credentials in prod and void the prod ones in dev?

2 Likes
4

We've experienced exactly the same problem Phil and have had to avoid using a development server/copy for any updates to the live system using ODBC/ESS. All changes have had to be made to the live system with all the associated risks, despite it being separated.

It was a crippling experience during go live and was not how we expected FileMaker to behave.

Regards
Andy

2 Likes