Problems with Error 3021 - No Current Record
in [Visual Basic]
|
From: David Youngblood on 16 Mar 2010 18:43 "Nobody" <nobody(a)nobody.com> wrote in message news:Oc1wrFVxKHA.1548(a)TK2MSFTNGP02.phx.gbl... > "Paul Clement" <UseAdddressAtEndofMessage(a)swspectrum.com> wrote in message > news:21tvp5lha9ckpb75qrsh06dh67gd2v2b5r(a)4ax.com... >> On Tue, 16 Mar 2010 10:33:10 -0700, Martin <ironwoodcanyon(a)gmail.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. >> >> No problem. After calling AddNew and Update the record pointer is still >> in no man's land (e.g. no >> current record). >> >> Like I said, try a MoveFirst or a Move to establish a valid row position >> in the Recordset. >> >> >> Paul >> ~~~~ >> Microsoft MVP (Visual Basic) > > Incorrect on all counts, how are you still as an MVP anyway? Maybe you > should go to the .Nxt group where you belong. > > After calling AddNew, the new record becomes current. That may depend on the back-end db and/or access method. With MSJet/DAO, when you call Update after an AddNew, the record pointer returns to the previously current record. If that was <no current record>, as would be the result from a nomatch, then the pointer returns to <no current record>. If you want the new record to be the current record you can call Bookmark = LastModified immediately following the Update. This may be what the OP needs. With rst .AddNew ' Fill in fields .Update .BookMark = .LastModified End With Personally, I consider <no current record> to be a valid state for a recordset, and in most cases I simply ignore error 3021, or at most display "No current record" in a status bar or label. David
From: Henning on 16 Mar 2010 20:06 "Nobody" <nobody(a)nobody.com> skrev i meddelandet news:u4aoy9UxKHA.4492(a)TK2MSFTNGP05.phx.gbl... > "Henning" <computer_hero(a)coldmail.com> wrote in message > news:%23HOaWZUxKHA.2432(a)TK2MSFTNGP04.phx.gbl... >> >> "Martin" <ironwoodcanyon(a)gmail.com> skrev i meddelandet >> 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. >>> >> >> What happens if you do a MoveFirst before doing the Seek? I'm only using >> SQL queries when accessing db's, so I don't know what happens if the Seek >> is performed when the last record is the current. >> >> /Henning > > I am not sure about what situation you are asking, but one has to check > for BOF and EOF before using MoveFirst in case the recordset is empty. > > If the current record is the last record in the table when he calls .Seek, will that throw the error? /Henning
From: Jon Lewis on 17 Mar 2010 06:10 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 "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 09:14 On Tue, 16 Mar 2010 16:41:02 -0500, "Nobody" <nobody(a)nobody.com> wrote: � > No problem. After calling AddNew and Update the record pointer is still in � > no man's land (e.g. no � > current record). � > � > Like I said, try a MoveFirst or a Move to establish a valid row position � > in the Recordset. � > � > � > Paul � > ~~~~ � > Microsoft MVP (Visual Basic) � � Incorrect on all counts, how are you still as an MVP anyway? Maybe you � should go to the .Nxt group where you belong. You quite obviously didn't test this scenario did you? Try the below code: Set rs = db.OpenRecordset("TableName", dbOpenTable) rs.Index = "PrimaryKey" rs.Seek "=", "PrimaryKeyValue" 'Value should not exist If rs.NoMatch Then rs.AddNew rs.Fields(0).Value = "PrimaryKeyValue" rs.Fields(1).Value = "Col1Value" rs.Fields(2).Value = "Col2Value" rs.Update Debug.Print rs.Fields(0).Value 'Should fail with no current record End If � � After calling AddNew, the new record becomes current. Also, if there was no � current record before calling Update, you are most likely to get an error � before calling Update when accessing one of the fields, because there is no � current record. Huh? There is no current record "after" calling the Update. � And you can't do MoveFirst or Move to establish a valid row position if the � recordset is empty. You most certainly can after adding a new row, like I said. Paul ~~~~ Microsoft MVP (Visual Basic)
From: Martin on 17 Mar 2010 11:24
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. >> >> >> >> >> >> > |