Forum Home
Press F1
Thread ID: 83027	2007-09-16 09:35:00	MS Access Error 16389	Stuart666 (12837)	Press F1

Post ID	Timestamp	Content	User
591752	2007-09-16 09:35:00	We have an MS Access ADP project at work. The application has worked fine for the last two years, but recently has started displaying a error message. This occurs when the following code runs on a Lost Focus event - Private Sub cboClient_LostFocus() On Error GoTo Err_cboClient_LostFocus DoCmd.DoMenuItem acFormBar, acRecordsMenu, acSaveRecord, , acMenuVer70 Exit_cboClient_LostFocus: Exit Sub Err_cboClient_LostFocus: MsgBox Err.Description MsgBox Err.Number Resume Exit_cboClient_LostFocus End Sub The purpose of this code was to update a form with client details after the client had been selected via the cboClient Combo box. The error message was Reversed Error, while the error number was 16389. After displaying both the description and error number, the code resumes, however the form does not update, with the client address datails, until the form has been closed and reopened. I felt that this problem started after a microsoft update, but are not 100% sure. Any ideas on whats going on??	Stuart666 (12837)
591753	2007-09-16 11:53:00	Is that code selecting an option from the menu? If so that's completely mad - it's bound to break if the user changes their configuration. The solution is either to reconfigure the menus (quick, dirty and at best a temporary solution) or replace it with reliable code (so this won't happen again a few months or years down the track). I would definitely take the second option myself - accurate data is too valuable to entrust to bad code.	TGoddard (7263)
591754	2007-09-16 21:13:00	Hi Stuart and welcome to PF1! I don't entirely agree that this is 'completely mad' because this technique is often used and the menu structures in Access are usually pretty stable. I think you will find this is a 'Reserved' error and not a 'Reversed' error. Is this a multi-user database? What version of Access are you using? Also, has anything else within the database changed? Depending on the set-up there may be ways and means around this error. If this is a multi-user database, then open the form in design view, select menu option Edit > Select Form, menu option View > Properties > 'Data' tab > 'Record Locks' > set to 'Edited Record'. If this doesn't fix the problem then (assuming the code is crashing on this line) change this line of code: DoCmd.DoMenuItem acFormBar, acRecordsMenu, acSaveRecord, , acMenuVer70 to this: DoCmd.RunCommand acCmdSaveRecord If that doesn't work, a record is automatically saved when the focus shifts from one record to the next. You could simulate that using DoCmd.GotoRecord commands. Alternatively, have you tried using the code in the 'After Update' event instead of the 'Lost Focus' event? That way the code won't trigger if the value doesn't change. Lastly, is it really necessary to save the record at this point in time? As I mentioned earlier, if the form is bound to the underlying table, then the record is automatically saved when you move to the next or a previous record. HTH, Andrew	andrew93 (249)
591755	2007-09-16 22:48:00	Thanks for your input. The code "DoCmd.DoMenuItem acFormBar, acRecordsMenu, acSaveRecord, , acMenuVer70" was created by a MS wizard. We are running MS Access 2003 SP2 and the Server is running SQL Server 8.00.760 SP3 Maybe thick but I could not find the Records Lock Property. Tried shifting code to After Update event with the same results - 'Reserved' error 16389. Also tried using Runcommand acCmdSaveRecord as well in both lociations, also with same result. The only reason we were doing a SaveRecord at this point was to force the Form to update with the Client Information, otherwise we had to close and reopen the form for it to update.	Stuart666 (12837)
591756	2007-09-17 07:01:00	Hi Is this a multi-user database? You can set the 'record locking' property by following these instructions (with no other mouse clicks in between!) : open the form in design view, select menu option 'Edit' > 'Select Form', select menu option 'View' > 'Properties' (if not already visible) > select the 'Data' tab > find the 'Record Locks' property (2nd to bottom) > set this to 'Edited Record'. If you cannot see the 'Record Locks' property then select menu option 'Edit' > 'Select Form' again. If you still can't see it then you haven't followed the instructions to the letter (maybe copy these instructions to notepad, print and then follow without Alt-tabbing back and forth). When you say 'force the Form to update with the Client Information' what do you mean? It sounds like you entering data into a table where (for one of the fields) you select the client from a combo box, you then want to show a whole bunch of information from the client table and then carry on entering data into this table, and this table may be linked one-to-many back to the client table. Is that correct? If so, there is a way around this without having to force a save command part way through the data entry process. Assuming the record source of the form is a table on the many side of a one-to-many relationship with the client table, then create a new query that contains all of the fields from this table and all of the fields from the client table (except for the unique key from the client table, you will select that field from the other table). Save this query. Go into the design of your form, and select menu option 'Edit' > 'Select Form', select menu option 'View' > 'Properties' > 'Data' tab > change the record source to the name of your new query. Save and close. Provided the 'control source' names for each object on the form match the field names from the underlying query, then the form should still work ok. HTH, Andrew	andrew93 (249)
591757	2007-09-17 10:18:00	The Records locked property is not avaiable as this is a ADP projectn not MDB . Regards wheither this is a multiuser database, I would say yes . The data lives on the server in a SQL database . Multiple users access it via a MS Access frontend . The form Record Source is a Query View - SELECT TOP 100 PERCENT dbo . Jobs . JobNumber, dbo . Jobs . [Date], dbo . Jobs . ClientID, dbo . Client . Name, dbo . Client . AddressL1, dbo . Client . AddressL2, dbo . Client . AddressCity, dbo . Client . AddressRegion, dbo . Client . AddressCountry, dbo . Client . PhoneNumber, dbo . Client . FaxNumber, dbo . Client . email, dbo . Client . Website, dbo . Jobs . JobDescription, dbo . Jobs . OrderNumber, dbo . Jobs . DateRQD, dbo . Jobs . Contact, dbo . Jobs . Dept, dbo . Jobs . IssuedTo, dbo . Jobs . IssuedBy, dbo . Jobs . Quote, dbo . Jobs . Finished, dbo . Jobs . Invoiced, dbo . Jobs . QuoteValue, dbo . Jobs . InvoiceNumber, dbo . Client . OrderRequired, dbo . Client . Notes, dbo . Jobs . ComplianceCertNumber, dbo . Jobs . ComplianceCertRQD, dbo . Jobs . Canceled, dbo . Jobs . QBentered, dbo . Jobs . IssuedToID, dbo . Jobs . IssuedByID, dbo . Jobs . JobQuote, dbo . Jobs . Locked, dbo . Jobs . Service, dbo . Jobs . Printed FROM dbo . Client INNER JOIN dbo . Jobs ON dbo . Client . ClientID = dbo . Jobs . ClientID ORDER BY dbo . Jobs . JobNumber As near as I can make out, I'm doing what you sugest, however the Client details do not show until the form has closed and reopened . Forcing the save used to work, but as mentioned now just creates a error . Any other ideas .	Stuart666 (12837)
591758	2007-09-17 10:41:00	Hi Stuart My apologies - I did read the ADP part but promptly forgot.....so you cannot set the multi-user properties at the form level in an ADP project? Can you set the default record-locking properties under Tools > Options in an ADP project? At first glance the SQL looks fine. Ordinarily Access queries will return the fields from the one side of the relationship in the scenario you are using but I haven't tested that with SQL and ADP so maybe there is some sort of limitation there...... A few remaining thoughts: 1st : force the page to update by moving to next record and then moving back again. This simulates the save. Use the DoCmd.GotoRecord twice (one forwards, one backwards and then a set focus command to get the control back to the next object on the form) - check it out in your VBE / help file. But again I'm thinking that if there are issues with the other 2 forms of saving the record then this won't be any different although it may be worth a try........(see below)** 2nd : use Dlookup functions in the fields on the form but if the underlying query already has the values this would seem to be a very inefficient way of retrieving the data. 3rd : change the form layout to one of form with a subform (the form has the customer details) and the subform has the job details, but this would entail quite a bit of re-work when this used to work all along.....again very unsatisfactory. ** 4th : if the first method doesn't work, have any of the field properties in the underlying job table changed? In other words, are you trying to save a record at a point in time where one of the mandatory fields has not yet been completed? By the way, was this you? www.ureader.com Andrew	andrew93 (249)
1