Yes/No True/False

[DSTR3]

I have an Update SQL statement that I'm getting an error on.
DoCmd.SetWarnings False
UpSQL = "UPDATE tblTerminal SET tblTerminal.TerminalName = " & Chr(34) & Forms!frmBSTerminalNames!TxtStation & Chr(34) & ", " & _
"tblTerminal.TerminalActive = Forms!frmBSTerminalNames!ChkLocked, " & _
"tblTerminal.TerminalLocation = Forms!frmBSTerminalNames!TxtLocal, " & _
"tblTerminal.TerminalAddress = Forms!frmBSTerminalNames!TxtIP, " & _


"tblTerminal.TerminalTypeID = Forms!frmBSTerminalNames!TxtType, " & _
"tblTerminal.TerminalTouch = Forms!frmBSTerminalNames!ChkTouch " & _
"WHERE tblTerminal.TerminalID = Forms!frmBSTerminalNames!TxtID;"
DoCmd.RunSQL (UpSQL)
DoCmd.SetWarnings True

Its TerminalActive, it gets its value from a checkbox which is either 0 or -1 The field value in the table is set to Yes/No.....Is this wrong or is the SQL statement wrong. Thanks
DS

[DSTR3]

Tis is the error message that I'm getting.......



Cannot update <field name>; field not updatable. (Error 3113)

Possible causes:

• The specified field is part of a TableDef or dynaset-type Recordset object that cannot be updated. For example, this error occurs if you try to update an AutoNumber field.
• You executed a query that combines updatable and nonupdatable TableDef objects, and you tried to update one of the fields in the query's results (the resulting dynaset-type Recordset).

[pkstormy]

I'm assuming that you removed the line:

"tblTerminal.TerminalActive = Forms!frmBSTerminalNames!ChkLocked, " & _

and it then worked?

[DSTR3]

Yes I did remove it. Funny thing is that the line....

"tblTerminal.TerminalTouch = Forms!frmBSTerminalNames!ChkTouch " & _

has the same type of data

Thanks
DS

[DSTR3]

I found the solution. The field in the query did not exsist. I forgot that two years ago I changed the name. Microsoft help should have said that the field doesn't exsisit instead of all of the other mumbo jumbo. That would have made it a lot easier to find the solution. Thank you for your input.
DS

[pkstormy]

Microsoft errors have always been vague since some of the same errors are used to indicate other problems. To their defense, there would probably be a lot more overhead within MSAccess if it had to specify more details on each specific error.

I've found that MSAccess errors often get confused for the wrong thing - 'Locked by another user' being the biggest one that developers often get confused with this error being due to a locked record versus a problem with the *.ldb file being locked.

I'm glad you found the problem!