From: Jon Lewis on 17 Mar 2010 12:27 But when you get your error the recordset will be EOF or (BOF and EOF) so by testing for this you should be able to pin point where the problem lies. If you don't want to do this then good luck in resolving your problem some other way. "Martin" <ironwoodcanyon(a)gmail.com> wrote in message news:pbs1q59c54bjkji58ddo5nbtf2997lvrhe(a)4ax.com... > On Wed, 17 Mar 2010 10:10:31 -0000, "Jon Lewis" > <jon.lewis(a)cutthespambtinternet.com> wrote: > >>What are you trying to understand exactly? >>The fact is that the error you're getting indicates that there is no >>current >>record. Why? well .BOF & .EOF are both true (empty recordset) or just >>.EOF >>is true (there may be other circumstances - I don't know). >> >>If under some circumstances this is an issue for your app and under other >>circumstances it isn't, it's an issue! So before any Recordset method >>just >>do the .BOF and/or .EOF test to initially find out where the error is >>happening, then look at why and what to do about it. If the On Error >>statement won't trap the problem then see if you can. Checking for .BOF & >>.EOF is very common practice and necessary when working with a DAO >>recordset. >> >>There could be several reasons why this shows up on a clinet PC and not >>your >>development machine. Are the DAO libraries the same version for example? >> >>HTH > > Jon - > > Like I said, if I do a .Seek and .NoMatch is True then I'm not going > to try to update anything. And thus, I don't care about the record > pointer or BOF or EOF. (do I?) > > The only thing I'm going to do (if .NoMatch is True) is an .AddNew and > here again, as I understand it, the status of BOF and EOF have no > bearing. > > I can see where, if I was going to try to read or update some data, > then the record pointer would definately be of importance. > > Yes, the DAO libraries are the same - I installed the software on the > client's machine. > > >> >> >> >>"Martin" <ironwoodcanyon(a)gmail.com> wrote in message >>news:jnfvp5lv3ck85trkf94vujm8dkgo6votam(a)4ax.com... >>> On Tue, 16 Mar 2010 10:57:40 -0500, Paul Clement >>> <UseAdddressAtEndofMessage(a)swspectrum.com> wrote: >>> >>> >>>>� >>>> >>>>Keep in mind that when you use Seek or FindFirst and there is no match, >>>>the pointer in the Recordset >>>>is actually in no mans land. Both BOF and EOF will be False. That's why >>>>it's a good idea to perform >>>>a MoveFirst or Move to a current row in the Recordset when NoMatch is >>>>True. >>>> >>> >>> If I do a .Seek and get a .NoMatch then I'm going to be doing either >>> an .AddNew or I'm going to be doing nothing further with that >>> recordset. So why does it matter where the record pointer is? >>> >>> An .AddNew is not affected by the status of BOF or EOF is it? >>> >>> And, if I'm taking no further action with the recordset, then the >>> record pointer has no bearing on things does it? >>> >>> BTW, I'm not trying to argue with anyone here, I'm truly trying to >>> understand just how this works. >>> >>> >>> >>> >>> >>> >> >
From: Paul Clement on 17 Mar 2010 12:49 On Wed, 17 Mar 2010 08:24:30 -0700, Martin <ironwoodcanyon(a)gmail.com> wrote: � >There could be several reasons why this shows up on a clinet PC and not your � >development machine. Are the DAO libraries the same version for example? � > � >HTH � � Jon - � � Like I said, if I do a .Seek and .NoMatch is True then I'm not going � to try to update anything. And thus, I don't care about the record � pointer or BOF or EOF. (do I?) � � The only thing I'm going to do (if .NoMatch is True) is an .AddNew and � here again, as I understand it, the status of BOF and EOF have no � bearing. � � I can see where, if I was going to try to read or update some data, � then the record pointer would definately be of importance. � � Yes, the DAO libraries are the same - I installed the software on the � client's machine. What do you do after adding the new row? Do you close the Recordset (rsMainData)? Paul ~~~~ Microsoft MVP (Visual Basic)
From: Martin on 17 Mar 2010 13:31 On Wed, 17 Mar 2010 11:49:18 -0500, Paul Clement <UseAdddressAtEndofMessage(a)swspectrum.com> wrote: >On Wed, 17 Mar 2010 08:24:30 -0700, Martin <ironwoodcanyon(a)gmail.com> wrote: > > >� >There could be several reasons why this shows up on a clinet PC and not your >� >development machine. Are the DAO libraries the same version for example? >� > >� >HTH >� >� Jon - >� >� Like I said, if I do a .Seek and .NoMatch is True then I'm not going >� to try to update anything. And thus, I don't care about the record >� pointer or BOF or EOF. (do I?) >� >� The only thing I'm going to do (if .NoMatch is True) is an .AddNew and >� here again, as I understand it, the status of BOF and EOF have no >� bearing. >� >� I can see where, if I was going to try to read or update some data, >� then the record pointer would definately be of importance. >� >� Yes, the DAO libraries are the same - I installed the software on the >� client's machine. > >What do you do after adding the new row? Do you close the Recordset (rsMainData)? > > >Paul >~~~~ >Microsoft MVP (Visual Basic) No, the recordset is open at all times. I open it when the program starts up and close it only when the program is shutdown. After adding a new row (or after doing an update) the next thing that would normally happen is another .Seek as some other subroutine does it's processing.
From: Paul Clement on 17 Mar 2010 15:02 On Wed, 17 Mar 2010 10:31:23 -0700, Martin <ironwoodcanyon(a)gmail.com> wrote: � >� Like I said, if I do a .Seek and .NoMatch is True then I'm not going � >� to try to update anything. And thus, I don't care about the record � >� pointer or BOF or EOF. (do I?) � >� � >� The only thing I'm going to do (if .NoMatch is True) is an .AddNew and � >� here again, as I understand it, the status of BOF and EOF have no � >� bearing. � >� � >� I can see where, if I was going to try to read or update some data, � >� then the record pointer would definately be of importance. � >� � >� Yes, the DAO libraries are the same - I installed the software on the � >� client's machine. � > � >What do you do after adding the new row? Do you close the Recordset (rsMainData)? � > � > � >Paul � >~~~~ � >Microsoft MVP (Visual Basic) � � No, the recordset is open at all times. I open it when the program � starts up and close it only when the program is shutdown. � � After adding a new row (or after doing an update) the next thing that � would normally happen is another .Seek as some other subroutine does � it's processing. � If you're not doing anything with this Recordset other than seeking, adding and updating rows then I would suspect the error is somewhere else in your code. Based upon what you have posted I can't see a reason for the error unless you're using the Recordset for navigation or for checking the values of the columns in the existing rows. Paul ~~~~ Microsoft MVP (Visual Basic)
From: Helmut Meukel on 17 Mar 2010 20:29
"Paul Clement" <UseAdddressAtEndofMessage(a)swspectrum.com> schrieb im Newsbeitrag news:0a92q59ijqmvfbkn8teuaciasnp8a74djt(a)4ax.com... > On Wed, 17 Mar 2010 10:31:23 -0700, Martin <ironwoodcanyon(a)gmail.com> wrote: > > � >� Like I said, if I do a .Seek and .NoMatch is True then I'm not going > � >� to try to update anything. And thus, I don't care about the record > � >� pointer or BOF or EOF. (do I?) > � >� > � >� The only thing I'm going to do (if .NoMatch is True) is an .AddNew and > � >� here again, as I understand it, the status of BOF and EOF have no > � >� bearing. > � >� > � >� I can see where, if I was going to try to read or update some data, > � >� then the record pointer would definately be of importance. > � >� > � >� Yes, the DAO libraries are the same - I installed the software on the > � >� client's machine. > � > > � >What do you do after adding the new row? Do you close the Recordset > (rsMainData)? > � > > � > > � >Paul > � >~~~~ > � >Microsoft MVP (Visual Basic) > � > � No, the recordset is open at all times. I open it when the program > � starts up and close it only when the program is shutdown. > � > � After adding a new row (or after doing an update) the next thing that > � would normally happen is another .Seek as some other subroutine does > � it's processing. > � > > If you're not doing anything with this Recordset other than seeking, adding > and updating rows then I > would suspect the error is somewhere else in your code. > > Based upon what you have posted I can't see a reason for the error unless > you're using the Recordset > for navigation or for checking the values of the columns in the existing rows. > > > Paul > ~~~~ > Microsoft MVP (Visual Basic) I've read all postings and one question remains: With DAO and optimistic locking, what will happen if my Seek finds a match, I use .Edit, perform some things to collect all data, then use .Update and some other user has in the short time between .Edit and ..Update deleted this record? Wouldn't I get No Current Record? I personally had never this problem, because in all systems I programmed the users _never_ deleted records. Old records - older than 4 years - get transferred to an archive database. When I last visited a customer and looked into their archive folder, there were archive dbs back to 1995. <g> Helmut. |