Jump to content

This topic is 5279 days old. Please don't post here. Open a new topic instead.

Recommended Posts

Posted

Hiya,

FMP11/Win7.

We have 8 tables (.fp7 files) and each have their own layouts. A script in one of the tables needs to use a layout (using the Go to Layout command) from another table.

Is it possible to share layouts (or import like you can do scripts) between different tables. If this is the wrong way of doing things, what is the correct way?

Thanks

Posted

I'd re-create the layout in the other table.

Otherwise you ned to switch windows.

Posted

I'm sorry but that cannot be the solution.

What if I had 100 or even 1000 tables that needed the same layout from file x.fp7.

Would I need a 100 or 1000 copies of the same layout in each table? What happens if I make 1 change; i've got to repeat it so many times?

That is a very un-scalable way of doing things.

Posted

I'd like to help, but your misuse of FM terminology makes it difficult to understand the issue. In the interest of helping, I've commented your post:

"We have 8 tables (.fp7 files) and each have their own layouts."

Since FM7, each FM file can have many tables. Also, each FM file can have many layouts (and many layouts can be based on the same table occurrence).

"A script in one of the tables needs to use a layout (using the Go to Layout command) from another table."

Scripts are not in tables, they are in FM Files.

"Is it possible to share layouts (or import like you can do scripts) between different tables."

You don't share layouts between tables. Layouts are based on tables. Do you mean share layouts between FM Files? Well, the key question to me is why do you have many FM Files? I'd bet you've converted a preFM7 solution. However, even in a multi-file solution, you wouldn't share layouts, since layouts are based on table occurrences. You wouldn't need two Customer forms, for example. So, this question puzzles me:

"What if I had 100 or even 1000 tables that needed the same layout from file x.fp7."

Why would 100 different tables need the SAME layout?

Posted

I'm sorry but that cannot be the solution.

What if I had 100 or even 1000 tables that needed the same layout from file x.fp7.

Would I need a 100 or 1000 copies of the same layout in each table? What happens if I make 1 change; i've got to repeat it so many times?

That is a very un-scalable way of doing things.

It is the solution; and you've got it completely backwards. Backwards and sideways really.

Put all the tables in one file. You're confusing Filemaker and database terminology very badly.

There is no such thing as "in each table." Doesn't exist.

Each FILE can have multiple tables; and a file can have hundreds of layouts.

There is also no such thing as 100s or 1000s of table needing the same layout.

I suggest you upload copies or clones or simplified examples of your files; and also describe what you're trying to accomplish.

Posted

Thanks guys.

The misunderstanding is coming from my heavy SQL background and i've inherited this FM setup, which started as FM5, then went to FM8, then FM9 and now onto FM11

So:

FM files = SQL databases

FM tables = SQL tables

FM fields = SQL table fields

FM layout = ??

The side of the total files is over 1GB so uploading is not an option.

Basically, this is the structure:

Contact.fp7 (customer details)

Dashboard.fp7 ('home' page, with buttons to the other files)

Inventory.fp7 (product details)

InvoiceList.fp7 (existing invoices)

PO.fp7 (purchase orders)

StatementList.fp7 (statement list)

Variables.fp7 (have no idea what this is for)

When creating a new order, what currently happens is (some of is all automated):

Start at Dashboard.fp7

Open PO.fp7 and shows a list of customers (I assume from Contact.fp7)

You select a customer then it jumps to a list of products (I assume from Inventory.fp7)

Once you have chosen the products, you have to go back to Dashboard.fp7 then click on New Invoice, which runs some scripts to actually create the invoice and deduct quantity's from Inventory.fp7

However, as part of the last bit, they want it to jump to the Invoice_Print layout. When I view the raise_invoice script, I can see there is a Go to Layout step, which is currently set to all_fields. I cannot change this to invoice_print as it's only showing me layouts from Inventory.fp7, and invoice_print is stored in StatementList.fp7.

Hence my question of being able to bring in layouts from one file to another.

Hope that makes sense!

Posted

1. The file size is not an issue. You can create clones.

2. A layout is a visible view of data from a specified table occurrence. Data from tables related to the table occurrence can also be viewed.

3. It is possible to create table occurrences in any file that reference the tables from any other file.

4. Therefore it is possible to create layouts in any file that display data from any other file.

So everything that has been recommended to you is valid and can be done and is routine practice. You CAN combine all the tables and layouts and scripts in one file.

But working successfully in a multi-file system can also be done and the same principles apply. If you are going to view or operate on data you must be on a layout based on the table that you want to operate on. If you are going to print invoices you must be on a layout that is based on the invoice table (or based on its Line Items table).

If the invoice print layout is in Statements.fp7 then you go to Statements.fp7, go to the invoice_print layout, isolate the invoice record you want and you print it.

FileMaker requires a more comprehensive understanding of how data is actually used and viewed. I would recommend you run through the complete tutorial that comes with FileMaker.

Posted

What file and what table is associated with the "all_fields" layout you're talking about? Also, is this just an intermediate step in the Raise_Invoice script? Does it then move on to call a script in the Invoice or Statements table?

Since you apparently have a complex and complete system that works, and you're a self admitted novice, why are you trying to change it?

Posted

Since you apparently have a complex and complete system that works

That's the point, it doesn't work as the client wants. It may well put in the correct info but they want it to finish on the invoice screen, not to have to go back a few steps and then manually find the invoice to print it out.

Posted

That's the point, it doesn't work as the client wants. It may well put in the correct info but they want it to finish on the invoice screen, not to have to go back a few steps and then manually find the invoice to print it out.

But the answer is still the same and it is standard FileMaker scripting. A script in file A calls script(s) in file B, passing parameters as necessary, then the file A script continues and finally stops, leaving you where you wish to be in file A.

If the invoice print layout is in the Statement file you have a script in statements that accepts a script parameter, invoice ID.

Pseudo code:

File A

Set variable $invoiceID; Invoices::invoiceID

Perform Script [ Statements, Print Invoice ( InvoiceID )]

Display dialog "We have printed your invoice"

Script "Print Invoice" in file "Statements":

Set variable $invoiceID; get( scriptparameter )

Go to layout invoice print

Enter find mode

Set field InvoiceID; $invoiceID

Perform find

Print

Posted

That's the point, it doesn't work as the client wants. It may well put in the correct info but they want it to finish on the invoice screen, not to have to go back a few steps and then manually find the invoice to print it out.

Without clones of the files; or example files; or complete copies of the scripts, it's basically impossible to do much to help you.

  • 3 months later...
Posted

Sorry for the no-show, been busy on other projects.

Thanks for the help so far, but could one of you explain how to merge all these files into one as I believe it will simplify what i'm trying to achieve.

I know that layouts cannot be merged (but can be copied into the new file) but the client seems intent on changing them all anyway and discarded non-used ones.

This topic is 5279 days old. Please don't post here. Open a new topic instead.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.