Run Times - Linked Databases

[Jarvis]

I am developing a database for a cabinetshop that will have the following four basic components:

CABINET DIMENSION INFORMATION

MATERIALS & VENDOR INFORMATION

LABOR INFORMATION

CUSTOMER INFORMATION

So far I have been developing everything within one database.

The components above each live in a separate table within the database.

The CABINET DIMENSIONS component is starting to take on a life of it's own and will soon be big enough to warrant it's own database.

I have been trying to keep these tables all within a single database for ease of backup and password protection.

THIS IS MY QUESTION:

If I ever wanted to produce a runtime application with all of this information would keeping it under one database streamline the runtime?

Can I produce a runtime application that consists of four distinct, linked databases or is it restricted to one database at a time?

Thanks for your help,

Jarvis

[bruceR]

1. You can do whatever you want.

2. I'd strongly suggest that the data and interface files be separate. That way if you come up with a bug fix or new feature, the user installs the interface file and they're done - no data import required.

[Jarvis]

Bruce,

Thanks for the idea about separating data & interface.

That had not occurred to me.

Jarvis

[Jarvis]

Bruce,

So the interface is a separate, related file. Right?

Can you recommend any place to read more about this strategy?

Thanks,

Jarvis

[bruceR]

FMForums for one. It's been covered here but I don't have links. For anything FM7 related, your starting point should be reading all the documents at http://filemaker.com/upgrade/techbriefs.html

[Ocean West]

Here is another valuable resource

http://www.filemakermagazine.com/index.php

[Jarvis]

Thanks guys.

Jarvis

[Jarvis]

Bruce & Stephen,

I watched a video at length last night that was produced by Matt Petrowsky.

He was the fellow that did the Scriptology thing with John Osborne.

I'm sure a lot of what he said went over my head but I think he was pretty specific about filemaker not being a good candidate for separating data from interface.

I am going to do more research in this. The separation sure makes sense intuititvely but as I understand it, is not practical in application.

I will go now to the link you recommended, Bruce

Jarvis

[DanBrill]

With FM 6 and earlier, separation is difficult at best, and then only pseudo separation. You'd probably have your solution, and then one additional 'report' file that doesn't contain any data, but is full of relationships and calcs to your other files. Since it doesn't contain any data of its own, this can be updated by you and shipped to end users without having to script data imports. But it is a pain to work with since everything is related data, and under the FM 6 relational model you can't get data two tables away without some calc field workarounds.

With FM7, its a whole new ballgame. Separation is easy as can be. Keep data in one file, scripts and layouts in another. In some situations you may also want to keep your calcs in a 3rd file -- what FM is calling a 'Business Logic' file.

So if you are using 7, it is pretty painless. If you aren't and are serious about distribution with easy changes to the interface and calcs, I'd upgrade now. It's that big a difference.

Good luck,

Dan

[bruceR]

"I watched a video...

I'm sure a lot of what he said went over my head but I think he was pretty specific about filemaker not being a good candidate for separating data from interface."

VERY doubtful that he would say that. This is one of the strongest features of FM7.

[DanBrill]

It depends how old the video is. It would be true about 6. The complete opposite is true about 7.

[Jarvis]

Bruce & Dan,

It doesn't take a whole lot to be smarter than I am about Filemaker.

The first time I even contemplated the concept of separating data from interface was when Bruce raised the topic. The concept caused a lot of consternation in my neophyte brain, so I have been trying to come to grips with it.

The video I referenced is on the ISO site: http://www.filemakermagazine.com/index.php.

It was published July 9 of this year and is about the third video down on the site.

The title of the video is Multi System Development.

I downloaded the Tech Brief PDF that Bruce recommended and I am about 10% through it. My limitation is that I am not a programmer. I am what the tech brief would call an SME: Subject Matter Expert. I know everything about how to sell cabinets and run a cabinetshop.

I need to learn how to develop so that I can talk with Developers. The people that do this database stuff all the time are always going to be out at the edge of concepts. I don't need to be at the front of the curve but in order to leverage the skill of a contract programmer, I need to be able to communicate with them. To do this, I need to understand how their job works.

My skill is the ability to frame the problem that needs to be solved.

Learning database helps me to compose the questions that need to be answered.

My goal for this particular application is to produce a list of all the questions you would ever ask a customer. I want the customer to be able to select an answer from a list of allowable answers. If I can drive decision making in this format I can produce triggers that cause activites in my shop.

Because of this input from you guys, I am now going to attempt to move all my scripts into one database, my calculations into another, and the data into a third.

A week ago, I didn't know I needed to do this.

(And now I want to do it in the Field Factory Format)

So thank you for your forbearance,

Jarvis

[bruceR]

That sounds like doing things the hard way. Move the data.

It's actually surprisingly easy. I don't know how complex your solution is so far, or how many files you are using, so maybe what you're talking about is easy because there isn't much to move. But let's start with a simple example. An existing single file that contains data and interface, and perhaps multiple tables in the single file. Here's one way to do it.

Save a copy of the existing file, suppose the existing file is CabinetMaster, you call the new copy CabinetData.

Go back to CabinetMaster. Add a file reference that refers to the existing file - a self reference. It will look like this:

file:CabinetMaster

Now, in your relationship graph, change all the table occurrences to refer to this file reference, watching to be sure that they still link to the correct table name.

Make sure everything works.

Now go back to file references.

Change file:CabinetMaster to file:CabinetData.

Now everything is linked to the external data file. You can strip out most script, relations, and layouts in the data file.

[Jarvis]

Thanks Bruce!

I'll take a look at it that way.

Jarvis