Oh... and PS... I talked to a FileMaker Pro rep today, and she had just had a demo of the next version. She said that they were not sure if it would be called "FileMaker Pro 7" or "X" or "Next"... but she was impressed. Not much more than that (so she could keep her job)... And she indicated that Developer, Server, and Ultimate should all come out at the same time as the regular product (I didn't ask about Mobile).
i ended up hitting all the message boards via google and found what i was looking for.
i wanted to have Database A open. when user is done entering data in A, they press a button that runs a script that opens Database B, and imports selected values from database A.
i was trying to figure out how to export from A into B, but couldn't get it.
one way to make it work (that i found) was to have A set to a single record, open B and have B import A.
that worked, but required two clicks instead of 1. if someone knows an easy way to break that down to 1 click instead of two, i'm all ears.
Why not just use a relationship from A to B, and then "Set Field" to the related record. I assume that there is some logical value relationship that you can tie into, and even if there is none, then you can invent one. There is no need to explicitly open database B, it will be there as a relationship automatically.
For one of the projects that I am working on right now I have a field with an automatic (unchangeable) value of "true" in every file so that I can have a default relationship between the databases (one of which contains all of my default values). I am even using that relationship to create a self relationship (and some finding trickery) so that I can get a list of all the unique values... Oh the games we have to play to emulate a "select distinct" SQL statement... come to think of it...
Are you just entering data into one record in database B? If so, why not simply put related fields into the UI on database A? I think you may be missing the real usefulness of relationships in FMP.
You are correct that you should have two databases, and I think you also have the data layouts correct. Here are the few more steps you need:
Make sure that you have matching fields in both databases for the customer ID (a strict number if that would work). If you were getting fancy you could have the ID field in the disease record database validate against the customer ID field in the customer database. Oh... and it would also save a lot of headaches if you constrained the Customer ID in the customer database to be unique (not in the disease record database though).
Now create relations in both databases linking to the other one matching on the ID fields. In other cases, you could even allow for creation of records, but I don't think you are ready for all the work validation on that requires...
Now in the disease record database create a header on the records and place some fields in it, each time choosing the field from the customer database (from file) as the source. So the only information about the customer information in the disease file is the Customer ID. You might want to not let them modify these fields... as a lot of users forget that they are modifying the information for all of the records for that customer.... (using merge fields is often a good idea)
And in the Customer database make a portal (look it up in the manual), and place the related fields in the portal. Also making a transparent button over all this information and attaching a "Go to Related Record" action step is a nice trick. This will allow for easy navigation to all of the records for an individual customer.
Oh... and PS... I talked to a FileMaker Pro rep today, and she had just had a demo of the next version. She said that they were not sure if it would be called "FileMaker Pro 7" or "X" or "Next"... but she was impressed. Not much more than that (so she could keep her job)... And she indicated that Developer, Server, and Ultimate should all come out at the same time as the regular product (I didn't ask about Mobile).
Did you have an estimated timeline for shipment? I have heard first of the year ? I am VERY anxious to check out the NEXT version. Supposed to kick serious butt.
Sorry... but the only details on the timing were "next 5 months... but I am giving myself a lot of leeway". Since the promo I got called on ends Dec 31 (but explicitly includes one year of upgrades in the price), as do a couple of other ones on the web site, my guess is February-March timeline (long enough not to piss off the people who take advantage of the specials...).
I am really hopeful, as that is about the time I want to roll out the project I am working on, and I would love to be able to distribute it as a single file (one of the rumors). If that fill could be cross-platform I would love it... Here's hoping that FM Developer 7 (or whatever) lives up to the limited hype...
I am really hopeful, as that is about the time I want to roll out the project I am working on, and I would love to be able to distribute it as a single file (one of the rumors).
What do you mean, that multiple relational databases will present themselves as one unified file? I could see that being both good and bad.
ensign: By that I mean that if you have a collection of what everyone else in the industry calls tables, you can put them all in one file. Right now if you have a database solution involving multiple tables you have to have multiple files for that solution. If you are sending someone the database you have to send all of the files, or backups, etc... This can be especially cumbersome in FileMaker Developer solutions.
There is also the chance that you could have interfaces that don't belong to a single table, so that you could write applications that aren't as bound to the concept of tables.
Comments
Oh... and PS... I talked to a FileMaker Pro rep today, and she had just had a demo of the next version. She said that they were not sure if it would be called "FileMaker Pro 7" or "X" or "Next"... but she was impressed. Not much more than that (so she could keep her job)... And she indicated that Developer, Server, and Ultimate should all come out at the same time as the regular product (I didn't ask about Mobile).
i wanted to have Database A open. when user is done entering data in A, they press a button that runs a script that opens Database B, and imports selected values from database A.
i was trying to figure out how to export from A into B, but couldn't get it.
one way to make it work (that i found) was to have A set to a single record, open B and have B import A.
that worked, but required two clicks instead of 1. if someone knows an easy way to break that down to 1 click instead of two, i'm all ears.
For one of the projects that I am working on right now I have a field with an automatic (unchangeable) value of "true" in every file so that I can have a default relationship between the databases (one of which contains all of my default values). I am even using that relationship to create a self relationship (and some finding trickery) so that I can get a list of all the unique values... Oh the games we have to play to emulate a "select distinct" SQL statement... come to think of it...
the person who will be using this has approx. 1,000 contacts already stored, and gets maybe 30 new ones per year. (database A)
however, these contacts are sending in requests for disease analysis on samples.
so although there are 1,000 contacts, we already have 14,000 disease records. (database
each 1 contact can and will have half a dozen or more unique disease records that are related to their account/ID.
i wasn't sure how to do that cleanly w/o keeping those two in seperate databases.
Make sure that you have matching fields in both databases for the customer ID (a strict number if that would work). If you were getting fancy you could have the ID field in the disease record database validate against the customer ID field in the customer database. Oh... and it would also save a lot of headaches if you constrained the Customer ID in the customer database to be unique (not in the disease record database though).
Now create relations in both databases linking to the other one matching on the ID fields. In other cases, you could even allow for creation of records, but I don't think you are ready for all the work validation on that requires...
Now in the disease record database create a header on the records and place some fields in it, each time choosing the field from the customer database (from file) as the source. So the only information about the customer information in the disease file is the Customer ID. You might want to not let them modify these fields... as a lot of users forget that they are modifying the information for all of the records for that customer.... (using merge fields is often a good idea)
And in the Customer database make a portal (look it up in the manual), and place the related fields in the portal. Also making a transparent button over all this information and attaching a "Go to Related Record" action step is a nice trick. This will allow for easy navigation to all of the records for an individual customer.
In summary... welcome to FileMaker Pro...
Originally posted by Karl Kuehn
Shoot...
Oh... and PS... I talked to a FileMaker Pro rep today, and she had just had a demo of the next version. She said that they were not sure if it would be called "FileMaker Pro 7" or "X" or "Next"... but she was impressed. Not much more than that (so she could keep her job)... And she indicated that Developer, Server, and Ultimate should all come out at the same time as the regular product (I didn't ask about Mobile).
Did you have an estimated timeline for shipment? I have heard first of the year ? I am VERY anxious to check out the NEXT version. Supposed to kick serious butt.
Greg
I am really hopeful, as that is about the time I want to roll out the project I am working on, and I would love to be able to distribute it as a single file (one of the rumors). If that fill could be cross-platform I would love it... Here's hoping that FM Developer 7 (or whatever) lives up to the limited hype...
Back OT, I am a FMP guru and look forward to version 7. Maybe it will actually support scroll wheels and respect dock placement...
Originally posted by Karl Kuehn
I am really hopeful, as that is about the time I want to roll out the project I am working on, and I would love to be able to distribute it as a single file (one of the rumors).
What do you mean, that multiple relational databases will present themselves as one unified file? I could see that being both good and bad.
There is also the chance that you could have interfaces that don't belong to a single table, so that you could write applications that aren't as bound to the concept of tables.