Continuous form - Auto Update a field
in [Help]
|
Prev: Auto restart possible ??
Next: Startup
From: David W. Fenton on 6 Mar 2010 11:10 Salad <salad(a)oilandvinegar.com> wrote in news:0tCdndrmcIz_7AzWnZ2dnUVZ_oudnZ2d(a)earthlink.com: > David W. Fenton wrote: > >> Salad <salad(a)oilandvinegar.com> wrote in >> news:uNKdnYL75uk9vA3WnZ2dnUVZ_t6dnZ2d(a)earthlink.com: >> >> >>>In the Before_Update event of the form, you could do something >>>like >>> Me.SerialNumber = Dmax("SerialNumber","YourTableName") + 1 >>>if it passes all validation checks. >> >> Don't you mean Before_Insert? If you use Before_Update it will >> change the value every time the record is edited, rather than >> each time a record is added (which is hat I understand was >> requested). >> > Personally, I wouldn't do it at B4Insert. I'd do it it at the > save time in case the added record is aborted. But I'd probably > have a > If Me.NewRecord then > statement preceeding the calc if I were to use that method. Huh? BeforeInsert is cancellable. But I guess you're saying you want to delay the getting of the serial number until the record is actually "undirtied." Adding in the .NewRecord test would make that sensible, yes. I'll have to give that one a think. I like the idea, but in particular applications of mine, see it as a potential problem. In general, my philosophy is to save the records as quickly as possible, since I often do the record add in an unbound form, then open it in the editing form. This delays the assignment of the incremented field until certain data has been collected, and perhaps this accomplishes the same thing. I long ago abandoned for most apps trying to add and edit records in the same form because it was just too complicated to try to validate everything. Indeed, I'm thinking of one app that has had problems using a single form for both and I believe it's time to add an ADD NEW form. Doing so would eliminate a whole bunch of potential problems. -- David W. Fenton http://www.dfenton.com/ usenet at dfenton dot com http://www.dfenton.com/DFA/
From: Salad on 6 Mar 2010 11:51 David W. Fenton wrote: > Salad <salad(a)oilandvinegar.com> wrote in > news:0tCdndrmcIz_7AzWnZ2dnUVZ_oudnZ2d(a)earthlink.com: > > >>David W. Fenton wrote: >> >> >>>Salad <salad(a)oilandvinegar.com> wrote in >>>news:uNKdnYL75uk9vA3WnZ2dnUVZ_t6dnZ2d(a)earthlink.com: >>> >>> >>> >>>>In the Before_Update event of the form, you could do something >>>>like >>>> Me.SerialNumber = Dmax("SerialNumber","YourTableName") + 1 >>>>if it passes all validation checks. >>> >>>Don't you mean Before_Insert? If you use Before_Update it will >>>change the value every time the record is edited, rather than >>>each time a record is added (which is hat I understand was >>>requested). >>> >> >>Personally, I wouldn't do it at B4Insert. I'd do it it at the >>save time in case the added record is aborted. But I'd probably >>have a >> If Me.NewRecord then >>statement preceeding the calc if I were to use that method. > > > Huh? BeforeInsert is cancellable. Yes. However, it fires when you input the first field of a form. If sequential ids are the desired goal, I wouldn't do it in B4Insert, I'd do it when the record is actually saved. > > But I guess you're saying you want to delay the getting of the > serial number until the record is actually "undirtied." Adding in > the .NewRecord test would make that sensible, yes. Yes. A numeric key field, for most instances, doesn't say much to an end-user. If I saw CustomerID with a value of 20 or CustomerName of "Joe Blow's Mechanical Shop", I'd more easily recognize the name over the ID. In fact, I typically hide the IDs from the user. > I'll have to give that one a think. I like the idea, but in > particular applications of mine, see it as a potential problem. In > general, my philosophy is to save the records as quickly as > possible, since I often do the record add in an unbound form, then > open it in the editing form. This delays the assignment of the > incremented field until certain data has been collected, and perhaps > this accomplishes the same thing. I would agree with you if sequential numbering is not relevent. Then I'd use an autonumber as it basically does it's magic as a BeforeInsert event. > I long ago abandoned for most apps trying to add and edit records in > the same form because it was just too complicated to try to validate > everything. Indeed, I'm thinking of one app that has had problems > using a single form for both and I believe it's time to add an ADD > NEW form. Doing so would eliminate a whole bunch of potential > problems. > Each developer has his preferences.
From: clk on 8 Mar 2010 15:55 On Mar 6, 11:51 am, Salad <sa...(a)oilandvinegar.com> wrote: > David W. Fenton wrote: > > Salad <sa...(a)oilandvinegar.com> wrote in > >news:0tCdndrmcIz_7AzWnZ2dnUVZ_oudnZ2d(a)earthlink.com: > > >>David W. Fenton wrote: > > >>>Salad <sa...(a)oilandvinegar.com> wrote in > >>>news:uNKdnYL75uk9vA3WnZ2dnUVZ_t6dnZ2d(a)earthlink.com: > > >>>>In the Before_Update event of the form, you could do something > >>>>like > >>>> Me.SerialNumber = Dmax("SerialNumber","YourTableName") + 1 > >>>>if it passes all validation checks. > > >>>Don't you mean Before_Insert? If you use Before_Update it will > >>>change the value every time the record is edited, rather than > >>>each time a record is added (which is hat I understand was > >>>requested). > > >>Personally, I wouldn't do it at B4Insert. I'd do it it at the > >>save time in case the added record is aborted. But I'd probably > >>have a > >> If Me.NewRecord then > >>statement preceeding the calc if I were to use that method. > > > Huh? BeforeInsert is cancellable. > > Yes. However, it fires when you input the first field of a form. If > sequential ids are the desired goal, I wouldn't do it in B4Insert, I'd > do it when the record is actually saved. > > > > > But I guess you're saying you want to delay the getting of the > > serial number until the record is actually "undirtied." Adding in > > the .NewRecord test would make that sensible, yes. > > Yes. A numeric key field, for most instances, doesn't say much to an > end-user. If I saw CustomerID with a value of 20 or CustomerName of > "Joe Blow's Mechanical Shop", I'd more easily recognize the name over > the ID. In fact, I typically hide the IDs from the user. > > > I'll have to give that one a think. I like the idea, but in > > particular applications of mine, see it as a potential problem. In > > general, my philosophy is to save the records as quickly as > > possible, since I often do the record add in an unbound form, then > > open it in the editing form. This delays the assignment of the > > incremented field until certain data has been collected, and perhaps > > this accomplishes the same thing. > > I would agree with you if sequential numbering is not relevent. Then > I'd use an autonumber as it basically does it's magic as a BeforeInsert > event. > > > I long ago abandoned for most apps trying to add and edit records in > > the same form because it was just too complicated to try to validate > > everything. Indeed, I'm thinking of one app that has had problems > > using a single form for both and I believe it's time to add an ADD > > NEW form. Doing so would eliminate a whole bunch of potential > > problems. > > Each developer has his preferences.- Hide quoted text - > > - Show quoted text - Thanks everyone for your thoughts on this issue. I have it working using the before insert event of the form with a query to limit it to a particular serial/part id.
From: James A. Fortune on 9 Mar 2010 10:17
On Mar 6, 11:51 am, Salad <sa...(a)oilandvinegar.com> wrote: > > I long ago abandoned for most apps trying to add and edit records in > > the same form because it was just too complicated to try to validate > > everything. Indeed, I'm thinking of one app that has had problems > > using a single form for both and I believe it's time to add an ADD > > NEW form. Doing so would eliminate a whole bunch of potential > > problems. > > Each developer has his preferences. She sure does! :-) James A. Fortune CDMAPoster(a)FortuneJames.com I don't want to stereotype people, but it's hard not to when faced with stereotypical behavior. -- Ken Harrington |