Correct way to calculate fullname (1 Viewer)

khurram7x

Registered User.
Local time
Today, 18:21
Joined
Mar 4, 2015
Messages
226
I try to concatenate first and last name together after inputting from the Access form and then put results into the same table Employee table using trigger or stored procedure. When next time i try to edit the same record a popup appears say 'Another user edited this record and save the changes before you attempted to save your changes. re-edit the record.' This means that every time i've to requery and reach to the same record which will be slow as table grows.


How to do this thing correct, so that I don't see this message please?


Thanks,
K
 

Minty

AWF VIP
Local time
Today, 14:21
Joined
Jul 26, 2013
Messages
10,373
I wouldn't bother - you can create a calculated field in SQL to do this for you.
 

Ranman256

Well-known member
Local time
Today, 09:21
Joined
Apr 9, 2015
Messages
4,337
If you enter names into FirstN and LastN fields, there's no need for triggers.
You'd use a query to put the 2 fields together to see the full name.
No conflicts.
Are you using a split db,or a solo file?
 

sneuberg

AWF VIP
Local time
Today, 06:21
Joined
Oct 17, 2014
Messages
3,506
This means that every time i've to requery and reach to the same record which will be slow as table grows.
Maybe not if you have indexes on the fields but why are you storing a value that could be calculated whenever you need it?
 

The_Doc_Man

Immoderate Moderator
Staff member
Local time
Today, 08:21
Joined
Feb 28, 2001
Messages
27,313
Is this a case where the first and last names (and perhaps the middle name or initial) appear separately in the table? Also, that terminology is common to non-Access back end servers, so it would help to include that kind of information in the question.

If the name parts are already part of the table:

First, store the name parts separately. (And if it is a bound form with separate fields for the separate parts, you DO store those parts separately!)

Second, build a string function that takes the names and concatenates them "on the fly" by trimming them to remove spaces, checking for a middle name or initial to be present, and doing the reformatting as needed. If it is created as a public function, you can call it from a query, form, or report - any place it is needed.

Third, get your full name information from a query, not a table.

For the case where the name parts already are stored, including a full name in the same table is (sometimes) a subtle form of denormalization. Not one of the more onerous forms, but still technically so, depending on what is actually the prime key for that table. And it is CERTAINLY a duplication of data, since partial contents of the full name field would appear elsewhere in the same record.

OK, let's say you really want to store both name parts AND full name anyway. So let's address the direct "record has been edited" problem. Here's my take based on your comments in the problem description:

Using a trigger or stored procedure means you are letting the back-end do something for you rather than the front-end. But if the form is still open, so is the recordset that feeds it. Obviously, until the update, there is no data to "pull the trigger" so chronologically, the triggered update follows the form's update.

Most advanced back-end DB servers track the fact of a change by having some sort of internal sequence number on the records and they update it when they update the record. The back end recognizes the changed number and notifies the front end that the recordset no longer matches the records - they have later "generation" numbers (or whatever the DB is using for that kind of tracking.)

To avoid this, take the function I described earlier and update the full name field in a form BeforeUpdate event to do that concatenation in the front end BEFORE you save the record.
 

khurram7x

Registered User.
Local time
Today, 18:21
Joined
Mar 4, 2015
Messages
226
Yea, i'm using SQL Server backend.

Sometimes the solution is in front of you, but you can't see. Thanks DocMan for reminding me that I could do that in BeforeUpdate event on the form. Although I'm also updating couple of other fields in BeforeUpdate, but don't know for some reasons, thing didn't come to my mind about this field. Feeling so dumb!!!

Thanks for other explanation by the way, it helped me understand about the logic behind conflict.

BR
 

Users who are viewing this thread

Top Bottom