The action rolls back a new hire record, deleting it from a joining
table between employee and position - tblPosEmpRecord.
It's a many to many join.
The new hire action updates the employee with a new position and logs
it in the connecting record table.
If a user accidentally assigns the wrong position, they will need to
rollback the change and erase the connecting record, store a null in
the employee tables' position number, and store 'vacant' in the
position table for that record.
Here's the rollback:
Public Sub rollback()
On Error Resume Next
Dim temp_pos As Long
Dim temp_title As Long
Dim temp_salary As Currency
temp_pos = Forms!frmpersonnelmain!frmTAB1part4!curPos
temp_title = Forms!frmpersonnelmain!frmTAB1part4!curTitle
temp_salary = Forms!frmpersonnelmain!frmTAB1part4!curSalary
Forms!frmpersonnelmain![tblPosition.PosStatusID] = 2 'vacant
MsgBox "pos=vacant"
If Forms!frmpersonnelmain.Dirty Then
Forms!frmpersonnelmain.Dirty = False
End If
If Forms!frmpersonnelmain!frmTAB1part4!Designation = 11 Then
'<----rollback for new hire!
Forms!frmpersonnelmain![tblEmployee.PosID] = Null
If Forms!frmpersonnelmain.Dirty Then
Forms!frmpersonnelmain.Dirty = False
End If
Forms!frmpersonnelmain![cboHistFilt] = Null
MsgBox "new hire rollback REcord Deleted"
Forms!frmpersonnelmain!EmpStatus = 0 'inactive
Forms!frmpersonnelmain!frmTAB1part4!proPos.Requery
Exit Sub
End If
Forms!frmpersonnelmain!frmTAB1part4!PosID = temp_pos
Forms!frmpersonnelmain![tblEmployee.PosID] = temp_pos
Forms!frmpersonnelmain![tblPosition.JobClassID] = temp_title
Forms!frmpersonnelmain!MonthlySalary = temp_salary
Forms!frmpersonnelmain![cboHistFilt] = temp_pos
Forms!frmpersonnelmain![tblPosition.PosStatusID] = 1 'filled
MsgBox "gothere? rollback"
If Forms!frmpersonnelmain.Dirty Then
Forms!frmpersonnelmain.Dirty = False
End If
Forms!frmpersonnelmain!frmTAB1part4!proPos.Requery
End Sub
It works, I just don't like the three WRITE CONFLICT messages popping
off. It's very obnoxios.
Thanks,
Christian
You rather get rid of the message than fix the underlying problem? No
problemo: just add "on error resume next" to the top of your
procedure.
Some of us would rather know what causes this, and fix the root cause.
-Tom.
>From looking at the posts under this topic in this newsgroup, it seems
there is no way to turn it off.
I'm currently attempting to use update queries instead.
Very frustrating, especially when you have a deadline.
Christian
> Actually, the routines work like I want them to work.
Do you really want the routines to not work properly, give error
messages and fail to perform proper updates?
That's what you imply by saying "the way I want them to work".
>
> Very frustrating, especially when you have a deadline.
Frustrating is having someone too smart to accept the fact that he
needs to fix the problem, not hide it.
--
Bob Quintal
PA is y I've altered my email address.
--
Posted via a free Usenet account from http://www.teranews.com
He is trying to say the current record has not changed while it is
being changed ??
The update queries he was gonna try probably work better ??
PMG
Of course it does. That's how it's saving the changes. Any other way
and it won't work.
When I say *work* I will reiterate - it works exactly how I want it to.
Does that count for anything these days? Obviously MS Access doesn't
think so.
> He is trying to say the current record has not changed while it is
> being changed ??
That's a trick to save the record. It is a known trick and works
correctly. That's not what's causing the error. The error is caused by
me changing the value of one of the keys I believe - I need to do that
because I want the record to follow the employee to his new position.
There is no way to do this without programming.
>
> The update queries he was gonna try probably work better ??
FYI the update queries are doing the trick. No more Mama Access
complaining.
What's surprising me about the people who have commented on this topic
in this thread and other threads is that - you all take it for granted
that Mama Access knows best in ALL situations.
The whole reason why they have a set warnings off and on error resume
next is because when you're programming - you should be allowed to have
control of your freaking program.
Sure it's helpful to have error messages but having error messages that
you can't shut off is just plain wrong. I can't begin to explain all
the things I've tried in Access that by all rights should work but
didn't. I've had to find so many work arounds for what I wanted to do -
it's amazing they call this programming at all (sure, some don't).
So now that I've done the same thing with update queries as I orignally
did by passing variables - what's the difference MS Access?
There is none. That's why Access is wrong. In one case it regards the
action as a 'write conflict' error that there is no way to shut off -
and the same action in a different context it won't remark on at all.
Christian
> That's why Access is wrong.
Yes, it doesn't work very well for what you're trying to do, does it?
What's the solution? Have you considered rewriting your whole application
for some other platform?
I recommend that course reluctantly, for probably you wouldn't post here
anymore if you did. That's sad but it's probably for the best.
Oh well, our loss will be someone else's gain.
Hope this helps!
--
Lyle Fairfield
How old are you again?
Speak for yourself next time Lyle. Attempting to speak for the Access
community and this global usenet forum in general is about as mature as
your other weaselly little comments.
How about this - if you don't know the answer to the question then
stfu.
Christian
> How about this - if you don't know the answer to the question then
> stfu.
Well, sure. I won't feel guilty because you can use all the other helpful
suggestions you received.
--
Lyle Fairfield