Max Wanadoo
max.wanadoo at gmail.com
Wed May 28 03:16:15 CDT 2008
Hi Gustav, 1. The OnCurrent will fire many times for the same record if the structure of the form relies upon requering a combo box (for example), a list box rebuild, a save, a dirty made undirty (me.dirty=false), and so on. It is not possible to say that the OnCurrent will only fire once. On some forms I have it can fire up to 20 times. It will all depend on the code you have written and what you are trying to achieve. I am sure that some forms will only fire once, but the point I wish to make is that it cannot be relied upon to fire only once. Therefore retrieving the memo contents should not be done in the OnCurrent without some check to ensure that you have not already got it (ie, put the PK in a variable and only retrieve the memo field if the value changes). 2. Hmmm, can you be sure that if you go this route that the memo field will only ever be accessed via this 1-2-1 link. If not, then I would think that the lock needs to be on the memo table. 2p worth Max -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Gustav Brock Sent: Wednesday, May 28, 2008 8:56 AM To: accessd at databaseadvisors.com Subject: Re: [AccessD] VBA Unbound data entry / update form Hi Max 1. Not that I know of - for a main form. For subforms, however, it fires twice - one before the OnCurrent of the parent form and one after. 2. Good idea but - given the one-to-one relationship - that "lock field" could be located in the main table; that would save an updating round-trip to the memo table to set the flag. Also, this would save an update (reset of the flag) of the memo table should editing of the memo field not have been done. /gustav >>> max.wanadoo at gmail.com 28-05-2008 09:07 >>> Hi Gustav, With this method, don't forget that:- 1. OnCurrent can fire many times for the same record being loaded (depends on the structure and nature of the form and its functionality). 2. You may have to put a "Lock field" on the memo table to stop others loading the contents while they are being edited otherwise you will get them overwriting each others entries. Max -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Gustav Brock Sent: Wednesday, May 28, 2008 7:57 AM To: accessd at databaseadvisors.com Subject: Re: [AccessD] VBA Unbound data entry / update form Hi John Another option is to follow my advice #3 here: http://blogs.techrepublic.com.com/10things/?p=331 Leave your form bound but move the memo field off the current source table to a separate table with a one-to-one relationship and set your memo TextBox unbound. OnCurrent of the form, read the memo field into the memo TextBox. Store the initial content in a variable, say, strMemoLoad. OnExit of the memo TextBox, compare the content with strMemoLoad. If different, save the edited content to the memo field and fill strMemoLoad again (in case the user will make a later edit. Or set a flag at OnChange and save the content to the memo field at BeforeUpdate or AfterUpdate of the form. When adding a new record to the main table, add a new record to the memo table as well. /gustav >>> jwcolby at colbyconsulting.com 28-05-2008 00:34 >>> Susan, > John, are you asking how to use disconnected recordsets No, I am trying to discover how to use unbound forms for data entry editing. It is a similar but not identical thing. For example if you create a new record in an unbound form, there is no recordset to be disconnected. If you edit an existing record, then yes, kind of. You would (I assume) open a record, grab the field values, old values, names and such, and then close the recordset. That assumes a DAO recordset. You would disconnect the recordset (I assume) if you tried to do this in ADO. >or are you trying to talk yourself into writing a class instead? No, I am trying to discover the best way to emulate the functionality of a bound form. I do assume that this will involve custom written classes, but never having done this I am not certain of that. I have actually thought of taking a bound form, opening it to a record (bound forms use DAO recordsets, at least back in 2K and previous which this client still uses), then grabbing all the field values and "disconnecting" the form (and controls). This would give me a snapshot of the data as it existed as the form opened, and a method of determining if the data changed. -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com