Jump to content
Claris Engage 2025 - March 25-26 Austin Texas ×

portal or repeating field or something else?


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

Recommended Posts

Posted

Hi,

I am wondering which technique to use for the following desired goal?

I want to track incoming orders of groups of video tapes. I would like to create a new record for the whole group (rather then a record for each individual tape). This is all easy enough. But then I want to also have an individual record for each tape so that as staff members work on the tapes they can log their data. For example if I receive 15 video tapes I would want to create a PO containing data and instructions from the client in this record for all 15 tapes. Then 15 different people will work on one tape and will add unique data such about that particular tape. Some of the data will be the same but not all of it.

I've been reading and thought that I could do this using repeating fields. I created a repeating field where I input each tape # but I can't figure out how to make one row of the field be a unique record for the staff members that will be working on that tape.

Is there a way to do this? Or should I use some other approach? I've been reading about portals and that doesn't seem to be the way to go either.

Thanks for your help.

yanskasso

Posted

Don't use repeating fields, have separate tables (files in FM6) for "Orders" and "Tapes". A portal in Orders can show the list of tapes for that order. If you have multiple comments per tape, you might want yet another table for "Comments". This type of organization is the most correct from a structural standpoint.

-bd

Posted

So are you saying that I need to create a new database file for every tape we get. The point of programming the database is so that employees can input orders/tapes. If every time we get a new order I have to program a new file for each tape there is no point to using a database as it will take longer then doing it the old fashioned paper way that we are using now. We get maybe 30 orders a day with about 10 to 30 tapes per order.

I wanted an employee to be able to create a record of each new order. But if we need to actually program a new file for every tape in every order that could be 300 new files a day I have to create?

Maybe I am misunderstanding your instructions.

Thanks for you advice. cool.gif

yanskasso

Posted

Maybe I am misunderstanding your instructions.

I slight misunderstanding.

Use 2 tables: An Orders table and a Tapes table. You may need a few more tables to track additional parts of the process (Employees, Comments, etc.,) but it's not clear how much you need to track and how it relates.

If you still not sure how this works, you should probably study up on relational design.

Posted

I understand using more then one table but carpal tunnerl said to create a new file for every single tape which like I said would end up being thousands of files. When I read the book about the word "table" the only thing that I see is "table view" so I guess I am unclear as to what you mean by table. In the traditional sense of the word FileMaker 6 doesn't use tables. I guess what I am looking to do is to have a "table" with multiple tapes in it but then to have a separate record for each of the tapes. I have built relationships for all the duplicate data but I am unclear as to how to get the unique record to look at just the data for one tape rather then the data for the entire order.

I thank you for your advice. Does anyone know how to hire a file maker programmer that would be willing to sit with someone and teach them this stuff. I want to learn how to do all this rather then farm it out to someone completely. I have learned a lot but clearly there is a lot more to learn and I would like to hire a consultant.

So if anyone can answer the question and advise of how to find a consultant I would greatly appreciate it.

Thanks.

smile.gif

Posted

I think I figured out what carpal tunnel meant. I think I'm not explaining it well. I do have seperate files already for "orders" and "tapes". It sounds like what carpal tunnel is suggesting is to create a record for each individutal tape and then have a portal in the orders file list all of those tapes based on an order # or some such field. This is all doable but it's backwards of the way I want to do it and creates a lot of extra work for the staff.

What I want to do is first to create the orders record with ALL of the tapes and necessary data input in the orders record. Then I would like have a relationship from each tape # be accessible in a unique record in the "tapes" file. This way we don't have to make a record for each tape. We only have to make one record for the order.

Maybe there is no way to do this. If that's the case I guess we are stuck but I was hoping to do it as described above.

Hopefully that makes better sense?

Thanks for all your input.

grin.gif

Posted

Sorry about the 'tables' confusion. Tables are an FM7 thing, but basically a table is a file in FM6.

If I'm understanding your descriptions correctly, I think you need a join file between Orders and Tapes, we'll call it Tape_Order. So in this design, a Tape can be a part of many Orders, and an Order can have many Tapes listed on it. Attached is a diagram. Let me know if this helps or not.

Tapes.GIF

Posted

Hi,

I'm reading about joins and relationships now. Your diagram is matching what I am reading about so hopefully I will be able to figure it out.

Thanks. I'll keep you posted.

cool.gif

Posted

Acutally one quick question. Thanks for your patience.

In the tape_order file I would list all of the tapes (say 10 of them) right? And then I want all of them show up in Orders. But if I only want one of them to show up on "tapes" then it seems as of I am basically back to my original dilema.

So I still seems like each tape needs to be created as a separate record.

I guess I could put the tape #s in a value list and have the staff member select it but I was hoping to have each one be a different record so that different employees didn't accidentally change the data that someone else already input. If it's a separate record they can't accidentally change something.

Thanks.

This topic is 7322 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.