Visual Basic Language Reference
Erl Property
Returns an integer indicating the line number of the last executed
statement. Read-only.
Public ReadOnly Property Erl() As Integer
Remarks
If Visual Basic encounters no line numbers, it returns 0.

Sub Blah()
10 Dim rst As DAO.Recordset
20 On Error GoTo BlahErr
30 GoTo BlahExit
40 MsgBox "Yes"
BlahExit:
rst.Close
Exit Sub
BlahErr:
MsgBox "ERL returns: " & Erl _
& vbNewLine _
& vbNewLine _
& "But the Error didn't occur at :" & Erl & "!" _
& vbNewLine _
& "In fact Line " & Erl & " is Never Run!" _
& vbNewLine _
& vbNewLine _
& "Use <Ctrl><Break> to exit.", vbInformation, "FFDBA"
Resume BlahExit
End Sub

"Lyle Fairfield" <lylefairfield@aim.com> wrote in message
news:1136063632.045592.297260@z14g2000cwz.googlegr oups.com...[color=blue]
> Visual Basic Language Reference
> Erl Property
> Returns an integer indicating the line number of the last executed
> statement. Read-only.
> Public ReadOnly Property Erl() As Integer
> Remarks
> If Visual Basic encounters no line numbers, it returns 0.
>
> Sub Blah()
> 10 Dim rst As DAO.Recordset
> 20 On Error GoTo BlahErr
> 30 GoTo BlahExit
> 40 MsgBox "Yes"
> BlahExit:
> rst.Close
> Exit Sub
> BlahErr:
> MsgBox "ERL returns: " & Erl _
> & vbNewLine _
> & vbNewLine _
> & "But the Error didn't occur at :" & Erl & "!" _
> & vbNewLine _
> & "In fact Line " & Erl & " is Never Run!" _
> & vbNewLine _
> & vbNewLine _
> & "Use <Ctrl><Break> to exit.", vbInformation, "FFDBA"
> Resume BlahExit
> End Sub
>[/color]

And... Just in case Someone was wondering....

This is NOT a "DAO peculiarity in A97"!

--
Randy Harris
tech at promail dot com
I'm pretty sure I know everything that I can remember.

On 31 Dec 2005 13:13:52 -0800, "Lyle Fairfield" <lylefairfield@aim.com> wrote:
[color=blue]
>Visual Basic Language Reference
>Erl Property
>Returns an integer indicating the line number of the last executed
>statement. Read-only.
>Public ReadOnly Property Erl() As Integer
>Remarks
>If Visual Basic encounters no line numbers, it returns 0.
>
>Sub Blah()
>10 Dim rst As DAO.Recordset
>20 On Error GoTo BlahErr
>30 GoTo BlahExit
>40 MsgBox "Yes"
>BlahExit:
> rst.Close
> Exit Sub
>BlahErr:
> MsgBox "ERL returns: " & Erl _
> & vbNewLine _
> & vbNewLine _
> & "But the Error didn't occur at :" & Erl & "!" _
> & vbNewLine _
> & "In fact Line " & Erl & " is Never Run!" _
> & vbNewLine _
> & vbNewLine _
> & "Use <Ctrl><Break> to exit.", vbInformation, "FFDBA"
> Resume BlahExit
>End Sub[/color]

If I had to guess, I'd say the docs are simply imprecise. If one defines "the
line number of the last executed statement" to mean the number of that line or
the last line above it that has a number defined, then the code is working as
expected. The line number of "rst.Close" would then be 40 because the closest
line above it that has a number specifies 40.

On Sat, 31 Dec 2005 14:18:35 -0800, Steve Jorgensen
<nospam@nospam.nospam> wrote:
[color=blue]
>On 31 Dec 2005 13:13:52 -0800, "Lyle Fairfield" <lylefairfield@aim.com> wrote:
>[color=green]
>>Visual Basic Language Reference
>>Erl Property
>>Returns an integer indicating the line number of the last executed
>>statement. Read-only.
>>Public ReadOnly Property Erl() As Integer
>>Remarks
>>If Visual Basic encounters no line numbers, it returns 0.
>>
>>Sub Blah()
>>10 Dim rst As DAO.Recordset
>>20 On Error GoTo BlahErr
>>30 GoTo BlahExit
>>40 MsgBox "Yes"
>>BlahExit:
>> rst.Close
>> Exit Sub
>>BlahErr:
>> MsgBox "ERL returns: " & Erl _
>> & vbNewLine _
>> & vbNewLine _
>> & "But the Error didn't occur at :" & Erl & "!" _
>> & vbNewLine _
>> & "In fact Line " & Erl & " is Never Run!" _
>> & vbNewLine _
>> & vbNewLine _
>> & "Use <Ctrl><Break> to exit.", vbInformation, "FFDBA"
>> Resume BlahExit
>>End Sub[/color]
>
>If I had to guess, I'd say the docs are simply imprecise. If one defines "the
>line number of the last executed statement" to mean the number of that line or
>the last line above it that has a number defined, then the code is working as
>expected. The line number of "rst.Close" would then be 40 because the closest
>line above it that has a number specifies 40.[/color]

Yes. If
11 MsgBox "No"
is inserted before the Exit line, Erl is 11

BTW, who puts line numbers in code anymore?

Of course, if the rest of the code also was line numbered, then
50 rst.Close would have given an Erl of 50

P

Per Peter Sutton:[color=blue]
>BTW, who puts line numbers in code anymore?[/color]

I do it for many routines. If your error trapping writes info to a log, it can
be useful in quickly localizing a problem
--
PeteCresswell

On Sun, 01 Jan 2006 20:24:24 -0500, "(PeteCresswell)" <x@y.Invalid>
wrote:
[color=blue]
>Per Peter Sutton:[color=green]
>>BTW, who puts line numbers in code anymore?[/color]
>
>I do it for many routines. If your error trapping writes info to a log, it can
>be useful in quickly localizing a problem[/color]

It may be that you like typing more than me. However, I must admit
that on the _very_ odd occasion I have inserted a selected number of
line numbers where a recurring error has been intermittent and the
user(s) couldn't give enough information to track the problem down.

P

Per Peter Sutton:[color=blue]
>However, I must admit
>that on the _very_ odd occasion I have inserted a selected number of
>line numbers where a recurring error has been intermittent and the
>user(s) couldn't give enough information to track the problem down.[/color]

Once you start logging to a text file, it really grows on you. There *much*
less of having to subject the user to questioning trying to find out exactly
what happened.
--
PeteCresswell

If you get utility such as MZTools it'seasy to add and remove lin numbers
from VB and VBA procs.

Personally I on;y add them whene there is a problem whih is difficult to
track as well but they are very useful.

--------
Terry Kreft

"Peter Sutton" <psuttonr@killspam.com.au> wrote in message
news:lbdhr1506almdn5ad8mls49hj863pv17a4@4ax.com...[color=blue]
> On Sun, 01 Jan 2006 20:24:24 -0500, "(PeteCresswell)" <x@y.Invalid>
> wrote:
>[color=green]
> >Per Peter Sutton:[color=darkred]
> >>BTW, who puts line numbers in code anymore?[/color]
> >
> >I do it for many routines. If your error trapping writes info to a log,[/color][/color]
it can[color=blue][color=green]
> >be useful in quickly localizing a problem[/color]
>
> It may be that you like typing more than me. However, I must admit
> that on the _very_ odd occasion I have inserted a selected number of
> line numbers where a recurring error has been intermittent and the
> user(s) couldn't give enough information to track the problem down.
>
> P[/color]

Brain surgeons use scalpels as well.

"Terry Kreft" <terry.kreft@mps.co.uk> wrote in message
news:TF6dnV_irsCkJCTeSa8jmw@karoo.co.uk...[color=blue]
> If you get utility such as MZTools it'seasy to add and remove lin numbers
> from VB and VBA procs.
>
> Personally I on;y add them whene there is a problem whih is difficult to
> track as well but they are very useful.
>
> --------
> Terry Kreft
>[/color]

It seems apparent, from the variety of sentiments in this thread, that not
everyone shares the same opinion about the use of line numbers. I guess it
comes down to a "style" peference. Personally, I use them only for
debugging. For example, a situation where users report intermittent errors
that I can't reproduce and the Err.Description isn't enough to identify the
exact source of the error.

I too use MZTools, it makes it extremely easy to both add and remove the
numbers. I prefer not to leave the numbers in the procedures once the
debugging is completed. The problem is, as was pointed out in an earlier
thread on a similar topic, that MZTools only works with A2K and higher.

--
Randy Harris
tech at promail dot com
I'm pretty sure I know everything that I can remember.

Both rkc and I contributed [for free] line number code and I believe
such code or add-in exists at the mvp site? Don't know about rkc's but
mine removes numbers on demand, or removes numbers of previously
numbered lines before numbering them again. Is mine tested? No! Is the
code right there so anyone can modify it to meet his/her needs? Yes.
I think mine works with Access 97 but I have no way to check.

http://www.mvps.org/access/downloads/wzComment.zip

--
Terry Kreft


"Lyle Fairfield" <lylefairfield@aim.com> wrote in message
news:1136248574.144485.263980@g49g2000cwa.googlegr oups.com...[color=blue]
> Both rkc and I contributed [for free] line number code and I believe
> such code or add-in exists at the mvp site? Don't know about rkc's but
> mine removes numbers on demand, or removes numbers of previously
> numbered lines before numbering them again. Is mine tested? No! Is the
> code right there so anyone can modify it to meet his/her needs? Yes.
> I think mine works with Access 97 but I have no way to check.
>[/color]

New laptop, new keyboard response and the keys have been moved around (my
excuse anyway <g>).

--
Terry Kreft



"Terry Kreft" <terry.kreft@mps.co.uk> wrote in message
news:TF6dnV_irsCkJCTeSa8jmw@karoo.co.uk...[color=blue]
> If you get utility such as MZTools it'seasy to add and remove lin numbers
> from VB and VBA procs.
>
> Personally I on;y add them whene there is a problem whih is difficult to
> track as well but they are very useful.
>
> --------
> Terry Kreft
>
> "Peter Sutton" <psuttonr@killspam.com.au> wrote in message
> news:lbdhr1506almdn5ad8mls49hj863pv17a4@4ax.com...[color=green]
>> On Sun, 01 Jan 2006 20:24:24 -0500, "(PeteCresswell)" <x@y.Invalid>
>> wrote:
>>[color=darkred]
>> >Per Peter Sutton:
>> >>BTW, who puts line numbers in code anymore?
>> >
>> >I do it for many routines. If your error trapping writes info to a log,[/color][/color]
> it can[color=green][color=darkred]
>> >be useful in quickly localizing a problem[/color]
>>
>> It may be that you like typing more than me. However, I must admit
>> that on the _very_ odd occasion I have inserted a selected number of
>> line numbers where a recurring error has been intermittent and the
>> user(s) couldn't give enough information to track the problem down.
>>
>> P[/color]
>
>[/color]