Re: recognize EOF condition when using GoToRecord Action

lyle fairfield wrote:

I am sorry if it sounded as if I were suggesting the use of some
alternative to Kill and Open. I was trying to explain that VBA evolved
from ancient technologies, Quick Basic and Ruby, TTBOMK, and that it
contains archaic tools that use dos-like commands that are immediate
and can be catastrophic. Kill is one of these.
If I were using Kill for the deletion of anything but a temporary file
I would certainly write my own function which checked "Do you really
wanna", offered the option of backup, and check for file existence
before killing anything.

Where I use kill is when I filecopy a file to a new folder for permanent residence and then kill the original. By and large, it's a temp file. But I would always ask for a confirmation otherwise.

MS would serve us well by introducing a more modern alternative
scripting language for use with its Office programs. Such a language
might do what I describe above internally.

Or perhaps move it to the Trashcan instead of wiping out the file.

I did not recommemd that DoCmd.GoToRecord not be used, (although I
believe I have never used it.) I recommended that explicitly declared
Recordsets not be used except in unusual circumstances such as
massive, recursive manipulation of data.
If we must use a recordset, Seek, FindFirst, Find (ADO), MoveNext,
setting the Filter (ADO) etc are all excellent alternatives to
DoCmd.GoToRecord. After using them we could just check NoMatch or EOF
without risking attempt to move past end of file error.

It's not a command in my repertoire either.

Fifteen years ago I used Recordsets extensively with Access/Jet.
Before thart I used them even more extensivley in X-Base programs. And
I still use them with classic ASP. But not unless I have to.


On May 28, 11:32 am, Salad <o...@xxxxxxxxxxx> wrote:

lyle fairfield wrote:

For many years, VB experts have specifically recommended that GoTo
never be used. Like Kill and Open, it is as carry-over from a by-gone
age, and inherently dangerous.

Could your expand on your opinion of not using Kill? How else can one
delete a file? And with Open, if one wanted to write to a text file or
read a text file that isn't a typical CSV then what does one use?

I suppose someone could write malicious code with them but what if you
simply need to do a task that is non-malicious?

If it's recommended one not use Docmd.GoToRecord, what options are there
(you aren't keen on Recordsets) to use?






In Northwinds MS writes it own Function to handle GoToRecord errors,
such as trying to pass beyond EOF:

Function TryToGoToRecord(Record As AcRecord) As Boolean
On Error GoTo ErrorHandler

DoCmd.GoToRecord , , Record

Done:
Exit Function
ErrorHandler:
MsgBox Err.Description
Resume Done
End Function

But I think this is insufficient to handle the situation you are
describing. Regardless, I would recommend putting your code lines in
an error handling snippet, learning what error number arises on an EOF
error and doing some action when that error (number) occurs in your
error-handling block.

For even more advice than you want I may say that I discourage working
with recordsets except in very unusual conditions. We have beautiful
Access forms that allows us interaction with data. We have efficient
SQL that allows us to modify data painlessly and relatively safely.
And we have recordsets when we need to be slow, clumsy and vulnerable.

No, I don't hope to convert anyone. Obesity will disappear in North
America before the use of recordsets in inappropriate situations
disappears. But maybe there will be some newbie reading this who might
be influenced. I can hope.

On May 28, 10:08 am, MLH <C...@xxxxxxxxxxxxxx> wrote:

If I'm using the following in a procedure...

DoCmd.GoToRecord acDataForm, "FormName", acNext, 4

... how can I recognize the EOF condition? Using GoToRecord,
I find myself lost when trying to determine when EOF is reached.

I suppose it's too much to wish for something like...
On EOF GoTo Exit_Label


.

Relevant Pages