We have been using Filemaker for 2.5 years now, but one big problem is field matching when using the PHP API. I'm trying to explain our current situation and would really appreciate some professional input on this.
We are an event agency who organizes approx. 30 conferences per year, each conference in average 300 participants. For some of those conferences we are planning to use 1 database (for all) to handle onsite registration. Assuming 50% of our clients we do that, it would mean 15 projects x 300 participants = 4.500 records per year to handle with 1 Filemaker database.
All onsite tools (airport arrival lists, registration scanning, door scanning for head counts etc.) are already setup and working quite ok. The problem ist, we are currently developing an online dashboard which will allow us to setup online registration forms, send confirmation emails etc. and we want to link this with our Filemaker database using PHP API and Filemaker Server.
Pre-event use the online dashboard to gather registrations (starting 6 weeks before the conference)
During event use Filemaker (several clients as iPads, computers etc.) AND online dashboard (i.e. online evaluation, update flight details last minute etc.)
Each conference the online registration form looks a bit different:
- Sometimes we gather shirt sizes, sometimes we don't.
- Sometimes we offer them tour options, sometimes we don't.
- Other fields like name, flight details are repeating and always the same.
-> Now - how do we match those fields? We would actually like to be able to setup the forms using a WYSIWYG editor by basically just choosing.
NEW FIELD -> TYPE OF FIELD -> LABEL -> DONE.
But if we do it "random" like this, it's impossible to match it with Filemaker. We would need to match every field every time with the according field in Filemaker which would take pretty long and would be also pretty confusing for our administration staff.
Solution #1 I could think of:
When adding fields online in the dashboard, we are not adding type of fields, but the actual fields. That means:
We're adding the fields...
This we can do for all repeating fields. Problem about this solution is, that we will have a very long list of fields to choose from AND whatever custom field we need for a new project, we have to provide a set of custom fields to be used for that.
For example: One customer wants to know for some weird reason the hair color of participants. We don't have a field "Hair color" in FM. So we are using the prepared field "Custom_1" for this purpose and rename the label to "Hair Color".
All in all we are not very happy with this solution because of the bulky set of fields to choose from.
Solution #2 I could think of:
When creating the forms with the dashboard, we are just matching them randomly with a prepared set of let's say 100 fields in Filemaker which are named F1, F2, F3, F4, etc. So during online registration all the data goes into some of the 100 fields in Filemaker which we prepared, we don't really know yet in which one, but we make sure every single bit of information is saved.
Then when we actually start setting up the onsite registration tools, we match the fields by saying...
- "First_Name" data is in the field "F4"
- "Email" data is in the field "F10"
- selected "Tour" is in the field "F31"
...and so on.
I imagine if we save one test record using the registration labels as field values it should only take 5 mins to match it using appropriate scripts because we only have to spot field values vs. field names.
Question though is how to technically do that. We will use 1 Database for ALL projects and the matching will be different every time.
-> Change all "real" fields in Filemaker to a calculated field and add a new case "Case (xxx; xxx; yyy; yyy; database::project = "Toshiba"; database::F4 ) to each one of it? But I guess it would terribly slow down our database after a while if we have 30 projects and each field used in the layouts + scripts is a calculated field?
>> What do you think about my 2 solutions?
>> Any other idea how to meet our problem and solve it?
>> Or is my approach totally wrong and there's a simpler/different way doing it?
Thank you so much and I hope the problem we have is clear? If not please ask me what part needs more explanation.