get last error function

[ggh]

I'm trying to use the get(lasterror) function without much success. The user enters a student's ID number into a g_id field. A script then runs which creates a new record and sets the ID number to equal to g_id. In the field validation I have the ID number field set to "Unique". After the new record is created I turned on error capture and set user abort to off. I added a step:

If [get(lasterror)=504]

show custom dialog[ "this student has already been entered into the database"]

It's my intent to delete the duplicate record after (or before) the message, but I'm not getting the message suggesting the error is not being captured. Any suggestions?

[LaRetta]

It's my intent to delete the duplicate record after (or before) the message ...

There is another approach also ...

I would capture the ID in g_id and then test IT for Unique BEFORE creating the New Record. In this way, you can proceed after YOU'VE determined if it's Unique. You can either match it to a Value List (using Position() test based upon this ID field) or create a relationship from g_ID to ID and test IsEmpty(sameID).

It's easier to back a User out of a process before it starts. Since you're starting this process using a script, you can prevent it to begin with by using a calculation test and basing your script actions on THAT. If you are interested in these possibilities, let us know that also.

BTW, in your script, I think you're just missing a Set Error Capture [ On ], Commit after record creation, and an Else result if not Get(LastError) but I would prefer seeing more of your script/solution before saying for sure. And others may have a totally different perspective. Mine can be a bit strange. :shocked:

[ggh]

Ah, I'm not surprised that I've come up with an inelegant solution to this problem! I very much like the idea of catching the duplicate before new records are created - less work, slicker solution.

I've not used the isempty function in this kind of a way. I like the sound of creating a relationship between the g_id and the id field. Care to elaborate? I think I could push my way through it, but something tells me this is a basic technique I've been lacking!

[LaRetta]

I have one question, Tracy, before I explain this if I may?

Why are your Users entering the StudentID? I assumed that it is a number from elsewhere (preassigned by the school) that your teachers must enter to 'enroll' a student, is this correct? Because otherwise you can have the IDs generated automatically with Auto-Enter upon record creation

What I suggest will depend upon how you're currently set up so the above question is quite important. Regardless, I'll walk you through an easier New Record creation process.

LaRetta

[ggh]

You've guessed correctly. There is a HUGE student management system (sms) database with much of the information I need for my database. We are going to do a nightly download of data from the sms. Only 5-10% of the students will be registering for the after school program database I'm working on. The users will be registering kids into classes, creating classes, maintaining information on instructors, monitoring fees and payments, and generating reports on all aspects. I didn't want all of the kids showing up in the after school database so I was having them create records as they register kids into the program. I'll certainly take any suggestions!!

[LaRetta]

Then you're about ready to go. Create another table occurrence of your Students database in your graph (maybe called Duplicate ID). Join Students::g_id to DuplicateID::StudentID using =. Present g_id field to your teachers to enter the StudentID (remove real StudentID field to prevent access or modification). Also on the g_id, it's nice to remove ability to enter carriage returns. Select field, right-click to Field Behavior and click both tab and enter. Then Add New Student button would be something like:

Allow User Abort [ Off ]

If [ IsEmpty(g_id) ] ... test for blank and maybe proper patterns according to your StudentID (see below)

Show Custom Dialog [ OK ; "You must enter the Student ID." ] ... or fix it

Exit Script

End If

If [ not IsEmpty(Duplicate ID::StudentID) ] ... tests that a related (duplicate) StudentID exists

Show Custom Dialog [ OK ; "This student has already been entered into the database." ] ... or GTRR here (see 5 insertion steps below)

Set Field [ g_id ; "" ] .... that is two quotes together

Exit Script

Else

New Record Request

Set Field [ StudentID ; g_id ]

Set Field [ g_id ; "" ]

Commit Records/Requests [ No Dialog ; Skip Data Entry Validation ]

Go To Field [ first field for data-entry ] ... this is only to be nice to them

End If

That's it. A few other thoughts ... I'm unsure what your IDs look like but you might consider testing g_id for consistency before proceeding (see first line). If you would like to consider a validation that 1) Length is correct, 2) If dashes, they are in the right place, etc let us know. It will only require modification to the first If[] calculation. It is also nice to present your Users with the student they are attempting to enroll if Student already exists. If you would like this, replace Show Custom Dialog line "This student has already ..." (only that line) with:

Show Custom Dialog [ VIEW, TRY AGAIN ; "Student exists. View this Student or try another ID." ]

If [ Get(LastMessageChoice) = 2

Exit Script

Else

Go To Related Record [ Show Only Related ; Duplicates::StudentID ]

I also suggest you still let system generate unique IDs behind the scenes. Only you needs to know about them. This uniqueID must be unqiue AND never be changed. Working with school districts, THEY sometimes change this ID in their database (been there, done that). If that happens and the StudentID is changed in YOUR db to match it, it could orphan any related records you establish in FM. This process is only for creation of new records. StudentID can also be used (of course) to relate to your SMS master data for synch or import; but I suggest using proper relationship structures (with computer generated uniqueID) within YOUR structure.

Tracy, let me know if this needs to be tweaked to fit your specific needs or you want to add some pattern checks on that Student ID. Apologies for the length but your project is important. And I always feel it's better to over-clarify than under-clarify.

LaRetta

[ggh]

LaRitta,

I finally got a chance to try your suggestions. Sweet! Everything worked great. I especially like the go to related records touch and keeping my own IDs that the school can't destroy! Thanks for your suggestions. I'd never used the IsEmpty to check relationships - so cool!

[Saubs]

LaRetta, I think your script is very good. One question I have: Obviously the user will ultimately need to click the ADD NEW STUDENT button in order for this to work. Out of habit, I'm afraid my users would just click the enter key instead, and go back to what they were doing in another open window, unaware that the new record hasn't been created. Do you have any suggestions on how to get around this possible problem?

Many thanks--