Well, first of all you created 3 files.
I would suggest making one file with three tables.
Also, why are you duplicating records? Duplicating records is almost never a good idea.
Maybe tell us a little more about what you are trying to build and what the result should be. Also how you would like to work with it.
That way we know what we are talking about and might be able to give some more suggestions.
The naming conventions are also looking a little funcky. We might be able to make this all a little clearer.
But for now I'm going to wait for some more info.
thanks for your input. Let me explain a bit in more detail.
The 3 files are for no particular reason except that I am more comfortable working like that instead of tables in the same db. i know there are potential performance problems when running it on a server, but im not planning on that. Its just a bit more easy for me to do it like that, and it shouldnt really have a big influence on the scripts, right?
Basically i am building this to enable tracking simple projects. Each project can have mutiple "breakdowns", and each breakdown is comprise of several effects, which in turn are combined out of builds. There will be multiple revisions of the breakdowns in each project, and instead of putting together all the effects and builds again (even if they are changed) i like to just duplicate a breakdown and then change it into a different one.
Do you have any suggestions in terms of the naming? I didnt build any big projects yet, so i dont have much experience on that end :)
hope this helps, i feel like i really only miss the last bit to be able to do what i need to. i tried to wrap my head around it, but it took me a long time to figure out the single duplicating of childs, i just cant seem to connect the dots so i can duplicate them together with their grandchilds in one run.
I just helped someone else who also had multiple different files. The thing I found absolutely annoying about that is that when you are working in a file you very often go into "File" - "Manage" - "Database" to go and check out the fields, or to add some.
In your case you then always have to go to a different file, you have to open three files and switch from file to file when you need to be in a certain table.
I found that highly annoying and very unworkable.
But I guess it's a matter of preference. I however really don't see the upside of this.
In terms of naming conventions i always use this:
An ID number field with auto enter serial number is called "ID"
Then if you create a foreign key in another table you call it "BreakdownIdFk"
So you know that that's an ID coming from another table.
But I guess you can do with that whatever you want, as long as you know what's what.
I see you related everything to the Serial of the Breakdown table.
That makes everything really easy. And you don't even have grandchildren tables, only a main table and two children.
They are all identified by the "serial_bd"
So it's really just a matter of entering a table, finding the records with that serial_bd, duplicating them and setting the new serial_bd.
You also seem to have created elaborate ways of creating records in the portal. The only thing you have to do is allow the creation of records trough the relationship and you can create related records right into the portal.
I'll work on your file a little and I'll make it the way I would do it. Then you can have a look and see if you like what you see :)
Ok, here's how I would do it.
I deleted some scripts and fields. It seemed to me you were making it a lot harder then it really needs to be.
The way I did it now, you can just make builds and effects right into the portal itself.
And the button duplicates the whole set.
If you have any more questions just let me know.
If I were you I would also remove the ID fields from the portals, you really don't need them there.
I disabled field entry in Browse mode so you don't accidentally change an ID.
wow, awesome, thank you so much! i will dive into this and let you know how it goes :) thanks again, you made my day :)
Hi DaSaint, its been a while ;) I finally had some time again to get on this. What you put together works really well, you certainly are a star :)
The only thing that I cant figure out is how to relate builds to specific effects. Right now from what I can see, builds are directly related to breakdowns. What I like to do is have builds directly related to effects and effects then to breakdowns. Does that make any sense?
I tried playing around with it and introduced IDs to link them, but to no avail :(
Really appreciate your help, I love filemaker, but i got a lot to learn.
Is it then so that you have one breakdown.
To that breakdown several effects are linked.
And multiple builds can be linked to each effect.
That would mean that you would have to select an effect in the effects portal before you can see that effect's builds in the second portal.
Is that what you are looking for?
yep, one breakdown has several effects linked to it, and each of these individual effects has several individual builds linked to it. i was thinking initially to link the builds to the effect via an ID and the effects to the breakdown via another ID.
Hey Kay G:
Sorry for my late reply but I have it pretty busy right now.
I quickly slapped something together, adapted from my previous file.
The idea is as follows: You create a breakdown. Then create an effect that's linked to a Breakdown.
But then comes the tricky part. Before you create a build you need to select an effect, then create a build that will be related to that effect, and voila.
I also had to adapt the "Dupe" script.
But it seemed to be working after a little test.
Try it out and let me know what you think.
Don't forget!! Always select an effect before entering a build!!
if you like i can send you a link to the final thing, so you see what its all for.
That would be nice. I'd love to see it :)