DB.Execute Method not working

GUIDO22

Registered User.
Local time
Today, 16:26
Joined
Nov 2, 2003
Messages
515
Where once my code :

CurrentDb.Execute ("DELETE FROM STOCK_TMP_STORES WHERE StockNo =" & txtNewStockId)

worked - now it doesn't.....

The currentdb object, the table and txtNewStockId are all valid items. The call does not error - yet when I inspect the table - the record is still there!
Any thoughts on why this is happening?

(A similar thing is happening on another table when I insert a new record (using DB.Execute - INSERT INTO ..... ) - call does not error - yet record has not been appended to the table.)

Thanks
 
Try:
Code:
DoCmd.RunSQL ("DELETE FROM STOCK_TMP_STORES WHERE StockNo ='" & txtNewStockId & "'")

or:

Code:
CurrentDb.Execute ("DELETE FROM STOCK_TMP_STORES WHERE StockNo ='" & txtNewStockId & "'")
 
If StockNo is numeric then:
Code:
CurrentDb.Execute ("DELETE FROM STOCK_TMP_STORES WHERE StockNo =" & txtNewStockId), dbFailOnError
Otherwise Epic has made some suggestions.
 
RuralGuy said:
If StockNo is numeric then:
Code:
CurrentDb.Execute ("DELETE FROM STOCK_TMP_STORES WHERE StockNo =" & txtNewStockId), dbFailOnError
Otherwise Epic has made some suggestions.

Thanks - I can now trap the error!
 
RuralGuy said:
You're welcome. Glad I could help.

For your information :
This was only part of the problem - took me a while to figure but there was a record locking issue going on for some reason.

I could create the the record using the form which would write the info to a temporary table - when the user is happy and the data has been validated, the changes are appended to the 'live' table and the original temp record must be removed..... this was where the problem was happening. The delete code I was runining above woulld seemingly run OK but the record would still be there. Only closing the form and then re-opening again, and THEN running the delete code would the record actually be removed!

The error code generated from your suggestion mentioned a lock and I figured the form level record locking property may have something to do with it. The default is Edited Record - but only ever one user will be using this form and so I choose 'No Locking' and Hey Presto!
 

Users who are viewing this thread

Back
Top Bottom