Multiple Record Creation

[sboisvert]

I have 2 layouts (layout 1 and layout 2 for these purposes) that have the same field information from the same table within them but everytime I create a new record for layout 1 it will create a record for layout 2. I do not want this to happen, I only want layout 2 when I select a new record for layout 2.

Do I need to create a new table of fields for layout 2 or is their an easier way around this? A lot of the fields for layout 1 are common in layout 2, can a table with all the fields be copied and renamed as a new table or do they need to be recreated?

Thanks!

[IdealData]

You seem rather confused between LAYOUTS and TABLES.

A LAYOUT will show the fields from a TABLE, so if LAYOUT1 and LAYOUT2 are based on the SAME TABLE then each new record will appear in both layouts.

Stop thinking about creating tables to match your layouts - the process is quite the reverse.

If there is so much "overlap" on your fields then this could be a relationship requirement - but you'll need to explain a little more about your designs.

[sboisvert]

Ok, basically I will have 2 different requests for user to fill out information in fields, information that we will need to process their request.

A lot of the information will be common between the 2 requests but they each may have fields of info that are unique to them.

So if they choose layout 1 request based on what they want a record for layout 2 is automatically made creating unecessary records for layout 2. I only want layout 1 or 2 when they select which one they would like.

Does that make sense?

Think of it like layout 1 is a print request and layout 2 is a web request. Two different requests but have a lot of similar information.

[mr_vodka]

You should have a button to navigate between each layout. The script can then find only those records pertinent to what you want to display for them. You can imagine layouts just being different views into the back end record. Therefore whichever layout you create the record in is irrelevant; creation of a record is creation of a record.

[sboisvert]

I have a button for each Print and Web that will bring them to that layout. However if they choose print, an Web record will also be created, this will create Web records that are not needed.

[mr_vodka]

I am not sure I follow your last post.

[sboisvert]

I have a main page where I have a button for Print and a button for Web. If they click the Print button, it will take them to the print layout where they can fill out information for their job. The Web button does a similar function. Now each layout has iniformation that is specific to it but also information that is common (they have the same fields).

What I am trying to get it to do is if they want to fill out the print request record, that only a print record is created. Right now it will create both and the Web request will have info in the fields that are common. I'm thinking I need to set the Web in another Table but is their an easy way to convert that or do I have to do it all manually again and can I use information from other tables (the fields that are common)?

[mr_vodka]

Well yes you 'could' create another table but what is the issue with having the data in the same table. I am not understanding why they cant be in the same table. As I said earlier, you can just use buttons to script what type (web or print) records that you want to see by just finding records with data specific to each type.

Not knowing your structure, it is often correct to put like data in the same table.

[sboisvert]

Basically I just want it to create a print record when print is selected and a web one when a web is selected. It's creating one of each each time wether print or web is selected.

[mr_vodka]

I am trying to help you but I am afraid that you are not listening.

[sboisvert]

I appologize for my lack of experience in FileMaker, yours is obviously quiet extensive. The fact of the matter is that I am in fact listening, and trying to understand what is being posted.

In the future maybe having more patience with new users rather than assuming they know as much as you do about the application would make for a more pleasant conversation.

If anyone else has suggestions it would be greatly appreciated.

[KirkR]

Each layout has a context; a table occurrence (T.O.) that provides the data fields associated with that layout / screen display.

Creating a new record, creates a new record, no matter what layout you display the fields on. Layouts provide the vehicle to view different (or common) fields from a T.O. If you create a new record, then switch to another layout that has the same fields from the same record, the same data is displayed.

"GoTo Layout" will move to another layout of the same record in the database, and you can have the same, or other fields from that record on that second layout, extending the number of data entry fields, if required.

Normally, there would be data entry layouts, and data display layouts (reports).

Your explanations do not describe what you are trying to accomplish, so we are having difficulty assisting you. I have no concept what "one is web and one is something else".

[KirkR]

Creation of records only occur when you issue a NEW RECORD command, or add a record in a portal when the relationship defines "create records through the relationship".

What are you doing that is creating the new record??

[mr_vodka]

In the future maybe having more patience with new users rather than assuming they know as much as you do about the application would make for a more pleasant conversation.

I never assumed anything as you had rated yourself a beginner and furthermore you not the first new user that I have helped. We base our responses many times on what the posters rate themselves as.

Both IdealData and I had explained to you how layouts worked. If you had been confused with anything that we had said, you should have responded accordingly. Instead you kept saying the same thing over and over in each one of your posts. You did not respond to anything suggested or questioned. This is why I said that you were not listening.

I had said to you earlier that yes you could indeed duplicate a table and then import the data from the orig table into it but this goes against the rules of normalization.

http://databases.about.com/od/specificproducts/a/normalization.htm

Therefore I had asked you why you were so against having them in the same table.

I am not understanding why they cant be in the same table

You never responded. All you kept saying was the same thing over and over, instead of answering voids that could ultimately better assess your need and produce a solution. There is a difference between not understanding verses not responding.

I am sorry that you feel that I have been impatient with you as a new user but that wasn't my point.