If you are looking for FileMaker Help you've come to the right place. Join other FileMaker developers from all over the world to start a discussion, ask questions and get answers 24-7-365! You will not feel intimidated here! We are the Original FileMaker Forum - with over 17 Years of FileMaker Pro Help & Resources and the only FileMaker Forum covering every FileMaker Pro version and topic.

Log in to follow, share, and participate in this community and get real-time FileMaker help and answers! Check out existing discussions "many you will never see anywhere else"! See a question you can answer... post your response on the most used, referenced and the ORIGINAL FileMaker Forum. Tap or click the link to become a member.to get all that membership has to offer! If you encounter problems with our registration, subscription payment process or your account log-in, please contact contact us.

Importing/Updating Records - a User Experience

Hey all. I haven't posted for awhile, but here's a new question:

I work at a school and am the developer of the system (as well as a 5th grade teacher). The office staff needs to be able to import record information, updating such things as addresses, phone numbers, etc for each student in our database. They export this information from another system, the district-mandated database called Infinite Campus.

I'd like them to be able to update the records, and do so without me. I'd like to set up a script to do this. My question for you is do you allow the user to import or update records, or do you as the developer deal with that? If you allow them, how do you allow them to do that?

Some things I was thinking about with this:
1. do you directly import/update into the main table, or do you first use an import table to to then copy/update records?
2. I imagine there needs to be some sort of data validation for each field that is updated so that the wrong kind of info doesn't get put in a field.
3. Do you let them see the fields to import (the incredibly unfriendly match-fields box that pops up when you go to import), or do you program the fields to be matched to the import spreadsheet?

I'm very interested in how you accomplish this task - allowing non-developers to access a mildly complicated part of the work.

Thank you
jb

Warning: This is an Old ThreadThis discussion is older than 420 days. information contained in it may no longer be current

Re: Importing/Updating Records - a User Experience

First of all, I am not a developer. I do develop applications that are in use where I work and my wife works.

The application I wrote for her dental office is most analogous to your question. I started with a DOS application custom written in Clarion Professional Developer, a niche player 20 years ago. I was able to export the data in .dbf files, and then import these .dbf files into Filemaker.

I had several problems to overcome:
1) Dates - the switchover was not without problem. I had to use a known Clarion date and then use a correction factor to get the correct FM date (for each date field).
2) Key - the primary (patient) key field in use was a text file using five letters followed by three numbers (derived from the last names - or last and first - and then numbers to keep patients keys from being duplicated). The problem was that I did not want to continue using this key field calculation as it was cumbersome, so I switched over to a FM numeric auto-entered field. First I had to generate this key for 1,200 patients, then loop through 125,000 using the "old" primary key in order to generate a new "new" child foreign key. One problem: I first used a portal to find the child records and looped through the child records in order to assign the new numeric key. I used a portal with 25 lines - and it only assigned numbers to the first twenty-five child records (if there were more than 25). I had to change the portal to allow vertical scrolling in order to let the script "scroll" through all the child records.
3) There were other issues similar to the above. I had to change the text fields - some of the existing were in all capital letters, so that was another script. I finally combined all of the import script into one gigantic script that took three hours to run on a core two duo laptop.

My advice:
1) Import all the records and get the database working. Do not let anyone else work with the import settings. If you are FM savvy enough to do this then do it yourself. Then teach the users about updating the records.
2) You will get so familiar with this database if you do the above you will take for granted the difficulty factor. Build in safegaurds so that the users cannot delete all of the records, for instance. Limit privileges.
3) If you are in a hurry you might want to hire a professional. There are many that hang out here that could do a good job for you.

Welcome to the Original FileMaker Forum

With designated forums for almost every FileMaker topic...FileMaker Today is a free-to-join community where you can boost your FileMaker expertise, build better solutions and solve your technical challenges. If you're building FileMaker solutions, this is the place for you.