How to clear fields for new data entry

[plux60]

I am a new user of FM so this may be a silly question. I want to be able to enter data on a form and when I press an OK button the data is committed to the DB table and the fields are cleared ready for new data to be entered. Is that even a possibility?? I have tried but the fields display the old values entered and if I try to enter new data it overwrites the existing record in the table.Help!!!

[AHunter3]

What most people do is enter their data in the table where it's supposed to end up; then when they want to start with a fresh sheet to enter another record, they create a new record. But yeah, sometimes, rarely, there is such an extremely complicated set of required conditions before data entry can be deemed acceptable that, instead of putting validations on each field and trying to come up with decently-explanatory error messages, I do it the way you've described.

 

What you do is create one global field for each real field that you are going to have your end users do data entry into. The "OK" button first checks every requirement and parameter and throws very carefully & extravagantly tailored error messages (e.g., "You have selected a FasTrak client in combination with a blue parasol that is only available for standard shipping, with a shipping date that falls on a Friday, and you have not specified 'ship separately'. This will delay the entire order beyond the 3 days max for shipments to a FasTrak client") and exits script and waits for the user to change the data entry to something more acceptable. This usually involves a ridiculous number of If / Else If / Else If statements before you finally get down to business.

 

Once the data entry has been deemed acceptable, you do this:

 

 

New Window ["SaveData"]

Go to Layout ["Actual Data Entry" (DataTable)]

New Record/Request

Set Field [DataTable::Field A, EntryTable::g.GlobalField A]

Set Field [DataTable::Field B, EntryTable::g.GlobalField B]

Commit Record/Request

Close Window ["SaveData"]

Set Field [EntryTable::g.GlobalField A, ""]

Set Field [EntryTable::g.GlobalField B, ""]

 

Now you're ready for the next 'record' to be entered.

 

 

But aside from the circumstance specified above, I recommend not doing it. For the following reasons:

 

 

a) Global field data is temporary and perishable. If your user works doing data entry and has a record partially filled out but not OK'd yet, and the network goes down, or user's computer crashes, or user accidentally quits out of FileMaker and/or shuts down the computer, or any of a host of other interruptions of that ilk occur, all that data entry goes into the void, unsaved.

 

b) In a standard data entry situation, where user is directly inputting the data into the regular record, user may wish to look at prior entries as a reference. New window, do a Find for existing data, put them side by side, finish entry. If you're doing the "global fields data entry" trick, you have to script that kind of capability. Likewise for a raft of other chores that are built into FileMaker: you end up either reinventing a lot of wheels to accomodate your home-brewed alternative data-entry environment, or deprive your users of those options.

 

c) Editing existing data. How do you intend (if at all) that your users go back to an entry they made earlier if they realize they made a data entry error? In addition to the "how to find existing data" problem outlined in b) above, even if you DO provide them with a way to find it, do you intend that they do their editing in the regular normal way (regular fields) or would you populate the globals with the regular field data? You could do the latter, and diverge your script to save over an existing record rather than creating a new one if an existing record had been loaded, but that's more work for you. Or you could do the former, but then your users have to learn how to use the system in two different modes, which makes the db a bit harder for them to learn and become comfy with.

 

None of these are dealbreakers (as I said, I've done it, given sufficient reason), but life is simpler if you just teach people how to use FileMaker as it was intended to be used.

 

As I have said elsewhere: I just tell people "This is a database. When you open it, the first thing you'll be staring at is the first-ever record in the system, circa 1986 or whatever. That's how databases ARE. There are things that you do to create a new blank record and there are other things that you do to get to a specific record you want to look at. If you don't know how to do those things, you don't belong here yet anyhow."