Edit datathrough Form

[RustyRick]

I have a simple data base with 2 tables. One table is the pertinent Employee data. That includes a EmployeeID that I contrived myself with the first 4 letters of the FIRST NAME and the first 3 letters of the LAST NAME. I manually figured that out. Because I was new at this project.

But I figured out how to make the program do that automatically when I enter the employee's first and last name.

I have a form that sits overtop this table to populate the data. It's got some test date in it now c/w hand and manually calculated EmployeeID.

So now I figured out how to make the program do that calculation automatically.

So why when I cruse over the records and tab through the fields and the form shows the new EmployeeID, it doesn't update the table for that field?

Probably a dumb question.

 

[Beetle]

One table is the pertinent Employee data. That includes a EmployeeID that I contrived myself with the first 4 letters of the FIRST NAME and the first 3 letters of the LAST NAME.

Why? What's the purpose of storing this value? Certainly not a viable candidate value for Primary Key;

Stephanie Williams >>> StepWil
Stephen Wilson >>> StepWil

So now I figured out how to make the program do that calculation automatically.

And you did that how?

So why when I cruse over the records and tab through the fields and the form shows the new EmployeeID, it doesn't update the table for that field?

Hard to say, since we can't see your database and have no idea what you've done. Our telepathic powers only work on February 30th.

 

[RustyRick]

Why? What's the purpose of storing this value? Certainly not a viable candidate value for Primary Key;

The books I've read suggest that for a primary key. When you look at it, it immediately means something. Whereas a number, auto or not don't mean anything to anybody except the computer.

So help me understand why "RustRic" isn't a good candidate?


=Left([FirstName],4) & Left([LastName],3) in the "Control Source" of the field?

 

[pbaldy]

So help me understand why "RustRic" isn't a good candidate?

He already did, with examples of different people that would have the same value. It's like using birth date for a key; sooner or later 2 people will have the same birth date. You don't want something that could be duplicated. We have a couple thousand drivers. I guarantee that your key would be duplicated here. Heck, we have people with the same name.

 

[RustyRick]

Oh gottcha, I understand that issue. I thought there might be something ticking in the wings that could cause a melt down

 

[Beetle]

The books I've read suggest that for a primary key.

Then I would say you're reading the wrong books, because that's a poor suggestion.

When you look at it, it immediately means something. Whereas a number, auto or not don't mean anything to anybody except the computer.

There is no reason why a Primary Key value needs to, or should, mean anything to a human. It's purpose is so that the database engine can uniquely identify each record in the table. To effectively serve that purpose, it needs to be a value that can be guaranteed to be unique in every case. If it makes your users feel better to have some concatenated value based on the name displayed for them, feel free, but don't use it as the Primary Key. In fact, don't store it in the table at all, just display it wherever needed in a query, form or report.

 

[RustyRick]

Hmm thanks for that food for thought. I thought it best to use the PK to query other data or lookup fields. My semi-retired brain doesn't work like it use to. I'll have to think this through. Thanks very much!