Lending library check in help

[wenbow2003]

I am very new to Filemaker and am attempting to create a lending library. I work for a small television production and am trying to manage the props that go out to the various set/bays.

My problem is this: Some props have multiple numbers, and can therefore be divided and lent to more than one bay. THe main problem occurs when I check the prop back in. When I do this, it automatically selects the first prop checked out. This may not always be the first one back in. Is there a way to assign the history assets that are checked out a number, so that script can be written to coincide with that check out?

I apologize if this has been covered before, but I couldn't find it anywhere. Thank you in advance for any help that is offered.

[Fenton]

Basically, if the Prop has multiple numbers, then they need to be in the database, and they need to go out with the object, and come back in with it ( -).

If a "prop" was split, then there would need to be 2 records, like a join table, in the check out/in table, each with the common ID and each its own unique sub-IDs.

If the script is grabbing always the 1st, then it must just be looking at the first one of the props multiple possible numbers.

[wenbow2003]

Thank you for the quick response. As I am very new to this, I do have a couple of questions. Can there be more than 1 child table(I am assuming this is the same as a join table. If not, please correct me.) connected to do this? (I have attached a pdf picture of what my db looks like.) We would need to keep the history table, so we could track the prop's last bay(contact) in case it is not checked back in. Any help is greatly appreciated.

Props_Lending_Library_example.pdf

[Fenton]

Yes, you can have multiple child tables. A "join" table is a table where there are at least 2 IDs which are "foreign keys" from other "parent" tables. So it functions to "join" its 2 (or more) parents. The "prop check out/in" table functions kind of like this, as it ties the person (or whatever) who checks out a prop, as well as ties the prop checked out/in to the probs table (where its IDs come from). But it is more than a simple join, in that it also has a date (or timestamp) when the check out/in occurred.

I'm not quite sure how to the "multiple IDs" for a single prop. A question occurs: Is a "prop part" (of a divided prop) a "prop" of its own, which can also stand alone as a regular prop of its own, or is it only a part of that one part?

If it is always part of that one prop, then you could do the separate parts of a prob with just simple numbers, 1, 2, etc., or A, B, etc., in a text field, a return-separated list of values (much more useful than comma-separated, etc.).

The check out/in table would have an extra field for this "sub-prop id". It would be empty most of the time. You'd then have a separate calculation field to put the regular prop id with the sub-prop id.

PropID & Case (not IsEmpty ( SubPropID); "_" & SubPropID )

That would be what you'd use for most processing. In the check out/in table the calculated propID would look like, in 3 records:

1254 (regular Prop record, not split)

1254_1 (sub prop record)

1254_2 (sub prop record)

So the split ones could go different places.

In the main Prop table you would create a calculation to match any of these 3.

PropID & Case ( not IsEmpty (SubPropIDs); Substitute ( ¶ & SubPropIDs; ¶; ¶ & PropID & "_" ) )

With sub-props of

1

2

it would look like:

1254

1254_1

1254_2

That could match either of those 3 check out/in records.

That's the lightweight method. If the "sub props" can also be props of their own, then you'd need a join table off of Props, for the joins. So it would be a bit different. But it all comes down to matching IDs.