Relative references, multiple DBs with same name

[CyberSport]

Hey all. As much as I don't like to repost, I'm afraid my last one got buried under a complex thread, so I'm breaking out my response into a new topic.

The basic problem is 8 sets of DBs, all with internal relationships, with each set of DBs have the same names (eg, Central, Medical, Intl, etc)

Each set has many individual fxns and is housed indepedently at 8 unrelated sites. One master DB aggregates the data from all DBs, remotely. Am I going to have trouble with the internal relationships and grabbing data from 8 different DBs, all named the same thing, but with different IPs? Do I have to rename the 8 DBs with unique names for each site? While it would be easier to do so for one project, it would also involve changing hundreds of web pages and layouts.

Thanks.

Bevin

[falkaholic]

Could you give more detail as to what your set up is and what its doing?

[Kurt Knippel]

I would suggest using the Developer tool to rename each file with a reference to the site or function. For example General, becomes "sales.General" and so on.

This way your master DB can keep all of the sites and names straight.

Yes it will be a pain in the beginning, but once the paradigm is changed you can relax as the work will be done.

[The Bridge]

I don't know enough about your set-up to tell if this is feasible, but perhaps it would make more sense for your various databases to make the (update) call to the master database, not the other way around. This would certainly avoid any need to rename your various files, etc.

[CyberSport]

Cool. Thanks for all the help!

In re: more detail, say 2 schools each have 100 kids. The system for each school is 5 related DBs containing info on that kid.

The conference wants to hold info on the 200 kids in one DB, but only hold minimal info on each kid in the DB (mostly just the ID to relate them to their original files) and then have links to the kid's profile in one of the 5 related DBs. However, since each set of 5 DBs has the same name, the relationships will read ID::ID (Central IP xxx.xxx.xx.xx) for the first school and (Central IP yyy.yyy.yy.yy) for the next school and I want to make sure that the "relative path only" really does work when searching for multiple DBs with the same name, the only difference being their IP.

Kurt, in your suggestion using Developer, I would then have to rename web page tags that reference DBs? Not all that tough to do, since I do lots of general finds/replaces when customizing, just curious.

Peter, how would that work then when the master database would like to view the related record and ensuring that it goes to the right DB?

Thanks guys.

Bevin

[The Bridge]

Peter, how would that work then when the master database would like to view the related record and ensuring that it goes to the right DB?

In the approach I suggested, each of the 8 sets of databases would be related to the main database, not the other way around. The related files would update the data in the main file through scripting. For example, if someone adds a record in School 1's Database A, this would be handled by a scripted button which would also create a record in the main file and populate it with the entered data. If it's not essential that the main file reflect updated data immediately, you can script this sort of update to take place after hours, sort of a batch upload.

I'm still a little fuzzy on how your system is set up. Do each of the sets of databases have their own FileMaker-driven web sites, or is that a function of the main database? If the latter, would it make sense to combine all of the sets of databases into one set and allow the various schools to access their particular records/functions/etc. using a FileMaker client over TCP/IP? I sort of hesitate to ask this, considering the oft-political nature of these sorts of institutions.

Best of luck,

[CyberSport]

Well, you're exactly right about the political nature of colleges, which would not allow the totality of the data to appear solely on one joint machine. We're talking about data (financial aid, grades, etc) on Division I student-athletes, so having data all on one machine wouldn't work. As well, because the eligibility status of these kids (which is what the program tracks) changes perhaps instantly and the conference office would need to always have access to the real-time data, I thought it would be better to have the live connection vs the periodic updates

Further, the fxns of the conference office and the data they need on the kids is really quite limited, while the data/processes at each individual school are customized and extensive, and schools can have their system w/o the conference office having their system, so we need to make it with 8 completely self-sufficient individual programs and one overlooking all 8. I know...I sure did pick the wrong line of work!

Bevin