Filemaker program/data in Developer

[Triodes]

Hello,

I created a database with FM6Pro some time ago and would like to create a stand-alone version of it. As there are changes being made continually, I need to be able to change scripts/layouts without having to import new data at the customer's site each time I install a new version. Can developer be used to accomplish this? The database consist of 30-40 files, but most files also have scripts/layouts besides the data, do I need to remove this functionality and use the files for data only?

Thanks!

[danjacoby]

When you create a runtime version, don't check the box that says "Permanently prevent modification...".

Now you can open the runtime solution files directly in Filemaker and (provided you have full access) make changes to the scripts, layouts, etc.

At least, that's the way it's supposed to work; I haven't actually tried it myself.

[CobaltSky]

Yes, I can confirm that Dan is right - that *is* how it works.

Once the file has been bound (with developer) it can be re-opened with either FMD OR FMP to make cahnges, provided you uase a master password to open it and have not permanently removed modification access with the developer tool.

Note however, that because the runtime file will be associated with its bound application, you will need to open it using the File>Open dialog in order to bring it up in FMP/FMD.

[Anatoli]

Just hint -- the more you separate programming from your data, updates with new versions are easier and easier...

[Triodes]

Hi,

Thank you for the replies...

The situation is that the customer is running/using their database and I make changes at my own location. A few days later I drop by to install the new database ("executables" only).

With dBase there are seperate data and executable files which allow me to change the program while not having to disturb the data files. This allows me to change programming while the customer, in the meantime, is still able to enter data.

I hope I can make myself clear on what I mean. The question is if FileMaker in the stand alone version will allow the same.

[Anatoli]

The updates are not so easy with program and data in single file.

If you can separate those two entities in your design then is update easier.

It depends on your situation and business model etc.

[SteveB]

Developer does not specifically give you the capabilitiy you are looking for. You'd would have to separate the data from the scripts by careful design. Be very careful...I believe FM will only allow you to keep 50 files open at one time. My guess is that you would be better off in exploring a more automated update procedure and leaving the structure alone.

Steve

PS I doubt that there are many solutions that have split the data from the scripts in multi-file solutions.

[cjaeger]

just don't deliver half-baked programs to the customer.

I really don't like the idea of letting the customer enter thousands of records, and then the developer chooses to delete the fields the data is in, or just simply changes the calculation for the keys the data is related by. Proper versioning and carefull planning may help here.

Another suggestion:

Every time the customer closes the file(s), data is exported to a specific subdirectory. Then all records are deleted. The next time he opens the solution, all data is re-imported again. You keep this setup until you reach stable version 1.0.

[Anatoli]

RE: PS I doubt that there are many solutions that have split the data from the scripts in multi-file solutions.

Steve, there where 2 nice ladies at last DevCon and they have all their solutions written strictly in that fashion. Obviously it is much more difficult to program that way, but both will never use the "standard" FM way. No way. It was interesting seminar.

I've used it once for remote connection from factory in one city to HQ in another city and because the solution is running locally (single user) on each computer and only data are travelling through the Internet via set relations, it is FAST even on 128k line. I can send any time my update to workers; they just overwrite single file and have new version in 20 seconds.

Christian's suggestion is also very interesting one.

[SteveB]

I would have loved to do that, but I think to take an existing, working solution and rip it apart to separate the data from the scripts is asking for BIG trouble and loads of new bugs. As a concept, it is great but I'll bet that very few of the solutions created by all of the experts on this forum split the data from the rest of the solution.

I would love to have advise on how to accomplish the splitting of an existing solution.

Steve

[EddyB]

Hi all,

I may be asking a simple question but how do you seperate data from the database?

Do you mean you just have a seperate database with all the data in and a database with the nice design which relates to your data database?

Thanks

Ed.

[SteveB]

Yes, that is exactly what we are discussing.

Steve

[BertBoye]

I my search for an accounting system did I come across this solution http://filemakeraccounting.com .

The developer of this accounting solution has done that you all discus here, at lest from my point of view.

The solution has 9 db and the main file

[cjaeger]

there is a nice article about using single file interfaces at http://www.databasepros.com

[Anatoli]

With existing solution it will be quite difficult. Although in my above example it was done in existing solution but in new single "remote" module.

[Triodes]

Hi,

It's not that there are bugs, but new functionality is added every so often (new scripts, databases etc). This means I have to add this on-site and can do almost no preparation before-hand.

jim

[Triodes]

Hello,

Thanks for your posts...

Splitting data/scripts at this point is not a valid option as it would imply the same workload as starting from scratch. I also don't think FM is up to the multi relational setups I have running right now (multi-level relations, scripting on each level etc). Or at least is will be a back-breaker.

Jim