Help With "New Records" scripting

[fbugeja]

I have been working on updating a database for a school that I work with.

At this stage, entering a new student into the database at any time during the school year has been done by importing the student’s details via an Excel spreadsheet. This is fine if you are entering 1000 students at the start of the school year – but for 1 student, it is very fiddly.

I have tried to simplify the addition of one student into the database by adding an “Add Student” button which asks for the student’s firstname, surname, year (via a drop down menu), homeclass (via a drop down menu) and a Student ID number (which can be any unique number). The process involves 2 scripts: NewStudent1 and NewStudent2. The process does create the new student record – and a blank dummy record. You can see this by creating a new record, clicking any of the first 3 red buttons, and using the slider in the Status Area to move between records.

Can someone help me please. I’d like to know what I am doing wrong!

USERNAME: abc, PASSWORD: abc

Many thanks!

Frank

School_Database.zip

[Fenton]

There is a lot of scripting here to create a new record and fill in the name. That's OK. But normally one would do that into global entry fields, then create a record and set them into regular fields; after checking the global fields for this and that (such as duplicate names). That's what yours looks like it's trying to do.

But you are NOT entering into global fields first. What you are doing is going to a regular record and removing its data, to "initialize" for new data entry. Then you create a new record. So you end up with the new data replacing an existing record, and a blank record. Not so good.

So, either use global fields for data entry on that layout. Or just create a new record and let them fill in the data.

[LaRetta]

Also, your script StudentNew2 starts with Go To Layout [ Main ] but there is none. Change it to go to Student New perhaps?

And I see no true unique FM serials, IDs or validations. Allowing staff to add 'any old unique ID they wish' may cause problems for you down the road.

LaRetta :wink2:

[fbugeja]

Thank you both for your replies, Fenton & LaRetta. Both of you have been very helpful in the past.

I am still at the learning stage. From Fenton's response, I get the impression that I am "going overboard" to solving a simple problem - adding a new record. However, Fenton's response of "just create a new record and let them fill in the data" offers hope. Is it possible to modify to NewStudent1 script to go to the required entry (NewStudent), enter the student details (as a new record), then simply click the "Main Menu" button? (This would remove the need for the NewStudent2 script). Also, how could i deal with the issue raised by LaRetta of no true FM serial numbers, which would remove the possibility of the same StudentID number being entered twice?

Again, thanks for any assistance.

Frank

[LaRetta]

Hi Frank,

I won't answer for Fenton but I also spotted the over-work to create a new record. The first thing I did was actually delete your StudentNew1 script altogether. All you need (that I can tell), is:

Go To Layout [ New Student ]

New Record/Request

Go To Field [ first field so they can enter the name or whatever) ]

Have a MENU button there. When they are done adding the student, they can go home again. But it appeared that you were using Privileges to control what someone saw ... which didn't seem necessary on a new record (that they were entering data on anyway). I sensed Fenton's 'confusion' on the purpose of this also.

Others may call me anal for this, but I think EVERY table should have its own unique ID or serial. You may be required to have a 'school-assigned' ID but what you do within FileMaker is altogether different. You need to use NEW FM IDs/serials to relate your data - do NOT trust school IDs (been there, done that). I know of two dozen cases in which school IDs were changed. If you wish to validate the StudentID, that can be handled also. I would bet they are paper-trailed or used to transfer school records and such? So you must treat them as important bits of data (like a social security number or phone number). Do NOT use them to establish your relationships.

My 2 cents ...

LaRetta

[fbugeja]

Thanks LaRetta

Your 3-line script worked a charm! I deleted all names in the database then added students 1 by 1 using your script. Worked perfectly!

Again thanks - again!

Frank

[fbugeja]

LaRetta

Some slight changes to your script:

In using your script to go to a layout where data for the new record is entered, if nothing is entered and the Menu button is pressed, a blank record is created.

To get over this problem, I modified the Menu button script to delete the blank record:

Go to Record/Request[Last] // newest record is last record

If [isEmpty(Surname Field]) //check Surname field

Delete Record/Request[No dialog]

End If

Rest of script to go to Main Menu

Frank

[LaRetta]

I admit I didn't give you a finished script. I was just questioning the clarity of new record process. Yes, you'll need to trap. But you don't need to go to last record - they'll be ON current record. Don't display Status Area, don't let them navigate to another record, don't let them pass go (smile).

I would also validate before they leave. I'm too tired to think a script right now ... something like:

Click Menu button ...

Set Error Capture [ On ]

If ( IsEmpty(oneField) AND IsEmpty(anotherField) etc on all required fields). If ALL are empty

Delete Record/Request [ No Dialog]

Go to Layout { Main ]

Halt Script

End If

... then provide options using Custom Dialog. Tell them SOME field has data. And do they want to Finish this New Student record or delete it.

Show Custom Dialog [ FINISH ; DELETE ; "This record is partially complete. Do you want to Delete it or Finish it? ]

If [ Get(LastMessageChoice) = 1

Halt Script

Else

Delete Record/Request [ No Dialog ]

Go to Layout [Main}

etc ...

But if they haven't navigated off this new record, there is no need to go to the last. Script will fire on the current record. As your database grows, a process such as going to the last record will take longer and longer. And what if someone else creates a new record in the meantime? You'll be 'going to' and deleting someone else's new record.

[fbugeja]

Dear LaRetta

Again, Thanks for your help! The database is working as I wanted it to work!

Changes:

1. Whether you are entering a list of students via an Excel spreadsheet or 1 student by clicking the Add Student btn, FMP7 automatically generates a new (unique) StudentID number for that student/record. This eliminates the problem of manually entering a StudentID number in the spreadsheet or when the Add Student btn is pressed. More importantly, it prevents duplication of StudentID numbers.

2. I've included your scripts for my SAVE btn when you are on the StudentNew layout.

I've attached a copy of the updated database. U/Name and password: abc

Cheers!

FRank

MASTER.zip

[T-Square]

Frank--

The problem with ghost records is why Fenton initially discussed using global fields for data entry; basically, instead of opening a new record in the table and having the user enter the data directly in the table, you create a set of global fields that are put on the layout. The routine that calls the layout also clears the global fields out. The add button on the layout closes the window, validates the data entered, and then scriptomatically creates the data record. It's a little more work, but gives more control.

David

[Ugo DI LUCA]

Well,

Not that it is simple nor totally reliable without some workarounds, but FM8 brings new tools for that and we now can lock and control what the user is doing.

The new Get(RecordOpenState) is a wonderful tool to control it.

Edited November 9, 2005 by Guest

[fbugeja]

Dear T-Square

Thanks for your comments. At this stage in my usage of FileMaker, the MASTER.zip (MASTER.fp7) file that I uploaded is the most advanced project I have attempted. It has taken me months to get to this stage! To be honest, I am not fully conversant in the use of global fields. You are more than welcome to change MASTER and re-upload it to illustrate what you would do.

Again, thanks!

Frank

[Ugo DI LUCA]

My comment was only addressing FM8 users. I don't know if this is your case.

I don't really have time to look at your files, but here's a converted file of a demo I did upload to a french Forum involving the Get(OpenRecordState) function with no global fields to control record creation, modification and deletion.

Otherwise, I think you should find lots of demos and example here about implementing globals for record creation.

Validation_control_v2.fp7.zip