harvest

Hello James, if you already have an existing separated FM-App just save a copy of the GUI-file as a clone. Rename it to e.g. Reports.fp7, link the new File to the GUI-file, open this clone, delete all Interface-Layouts and there you are, or at least basicly... You will need many of the relationships that are present in the GUI-file so this is a fast way to get things working. Now all that has to be done is creating a selection of IDs of the data you want to print/save as PDF (this is usally done in the GUI-file)... and pass the ID-Collection from the GUI-file to the Report-file. There you will need a script to restore the selction of the data with help of these IDs in your layout for printing. Because the clone has the same TO-names as the GUI this shouldn't be to hard. My approach is collecting the IDs in the GUI-file, write it to a scriptparameter separated by linebreaks where the first line holds the information of what has to happen (print, save as PDF, preview...), looks like this: Print 12 134 135 198 go to a layout in the Report-file that references the correct data-table, write the scriptparameter to a globally stored field, that is related in a selfjoin-relationship to the ID of the table, GTRR of this relationship and there you are... Holger

Hi Genx, I can't explain in depth, what people do with a third layer in between GUI and data but I think, the goal is to get a totally flatened data-file without any calculations, relations... All these calculations are done in their so called Business-Layer which doubles or mirrors the table structure of the data-file. My goal with data and GUI separation was to get around these ugly updating-processes, we all know from FM < 7. When I did my first application in FM7 and thought about selling it a second time to a different customer I had to acknoledge that all layouts for printing in the GUI-files were based on the CI of the first customer. Thus I thought about a solution. First idea was to generate an account for layout-management in the GUI-file and teach people how to customize their reports. The second thought was about having a separate print-file. Datahandling between GUI and print-file isn't easy because GTRR can't be used, one has to transfer the selection of data that is to be printed e.g. via scriptparameter in a multiline-key. But it can be done and now I can give different customers a new GUI-files and there is no need to recreate reports. Have a nice Weekend Holger

Maybe it's these guys that have a third layer in between for business-logic. I've established a separate file for printing because I can distribute new GUI files to different customers without having to change reports which are customized for CI... Holger

"There can be some networking point in the separationmodel if you decide to have the interface file deployed on each workstation instead of the server!" Hi Sören, can you elaborate on that one? That is what I asked about in another thread. Thanks Holger

Thought about that to but it does not work on FM7, thus I will have to stay with the old one until the school is migrated to 8, 8.5, 9 or .... Holger

Hi I do the following: TO from Adresstable in GUI1, one Layout with only the PK of the Adresstable, now if you have your dataset selected, go to this layout and copy all rows, this gives you a collection of the selected PKs, seperated by CR, into the pasteboard, now go to GUI2, another TO of the adresstable, a globaly stored text field where you insert the pasteboard, establish a relation from this "multiline-PK-collection" to the PK of the table, perform GTRR and here you are This works for me, if I want to print in a separated printing-file Holger

Hi, I've written a programm for a school. The application has 3 GUI-files and 8 data-files. The Installation is in FM7, server is standard edition, clients are FMPro. For now the clients only hold a startfile that points to the central login of the main GUI-file on the server. Everything else is left on the server. For the time being performance is acceptable. Updating the solution is done by the schools admin: stop the server, swap the GUI-files, start server, done, a minute-job... Now I'm thinking about distributing the GUI-files to the clients machines to gain speed in the intranet and to limit some clients to simple data-input-capabilities by only giving them one of the GUI-files. Updating would be left to the clients or more work for the admin but that's OK. Has anyone tested the different approaches (GUI on server vs. GUI on client) and can share experiences? Holger

One table should be enough as fenton wrote. I keep one with globally stored Fields. Half of it are filled with information collected on login (login-date, users name, privileges...), the rest is used for dataselection etc. I have established a second table for fileinfo where I track development information as version, developers name, change-history... but that's not really needed Holger

Just to throw in another 2 cents I didn't watch the video either but I think, what makes it difficult is: there are two different approaches to separation. Model A has just data file(s) and GUI file(s) and in some cases separate printfiles while model B establishes a third layer in between data and GUI to hold the businesslogic. There are arguments for both solutions but I follow model A. From your description I suppose, the video shows model B where most of the calculations are dealt with in the businesslogic-layer. These hold the same tables and fields as the data-files and mirror the data to be worked on. Model A works like a charme for me (and my customers). New functionality can be added by just switching the GUI file. Some developers favor adding fields in advance in existing tables to be used when needed if you can't get hands on the original data-files. Just give it a try, it's worth it. I would never go back to the old ways of FM <=6. Holger

Hi Stash, why not use a texteditor before importing into filemaker? three actions of "find and replace" will leave you with a file, you can simply import into fm, just choose ";" or Tab as new separators Holger

Hi n1k0, how about a third table in between with only the unique places. This could be displayed via portal if you also export the PersonID to this table. Or perhaps a relationship based on the unique-key you have already generated, matched to a variable with value "1", and the PersonID? holger