Ok, why does THIS crash?!

  • Thread starter Maury Markowitz
  • Start date
M

Maury Markowitz

I've been struggling with various crashes and mysterious problems that don't
seem to make any sense. Don suggested ridding myself of code that talks to
the currentRecord, and that seemed to generally stabilize the app greatly.

Except on the main user's maching of course. Ok, why the heck does this code
blow up access?!

I thought that even talking to the recordset to see if it's EOF might be the
problem, so I commented that line out. Nope. Then I commented out the save
command. No help there either. So basically just setting those three
variables causes Access to crash out?

Hellllllppppp!

ADO, ADP app, everything on SQL Server, nothing local.

Private Sub AcceptButton_Click()
If Me.Recordset.EOF = True Or Me.Recordset.BOF = True Then GoTo ExitOut

If Me.status = "Posted" Then
Me.status = "Accepted"
Me.lastModifiedTimestamp = Now
Me.lastModifiedById = GetLoggedInUserId()
End If
RunCommand acCmdSaveRecord

End Sub
 
A

Albert D. Kallal

message


Can you run *just* the following command ok?
RunCommand acCmdSaveRecord
Click to expand...

Perhaps some required field, or triggers on the server side are setup here?

Also, you have:
Me.lastModifiedById = GetLoggedInUserId()
Click to expand...

Try putting in right before the above, a:

msgbox "logon id = <" & GetLoggedInUserID() & ">"

Also, does all your code compile before you try and run it?
 
D

David Phelan

Try working with the recordset clone.

With Me.RecordsetClone
.Edit
!status="Accepted"
!lastModifiedTimestamp=Now()
!!lastModifiedUser=GetLoggedInUserId()
.update
end with

Me.Refresh
 
J

J. Clay

Another thing that I have found is rather than use the RunCommand use:

me.dirty = False

Just seems to work better for me.

Jim
 
M

Maury Markowitz

Albert D. Kallal said:
Can you run *just* the following command ok?
Click to expand...

Yes, that works fine.
Also, you have:

Try putting in right before the above, a:
Click to expand...

I can see the value if I break on that line, the value is my name, which is
as it has always been.
Also, does all your code compile before you try and run it?
Click to expand...

Yup.

And like I said, it works fine on all the 2003 machines in the office, the
problem only happens on the 2002 installs.

I have a question. What _exactly_ is the difference between...

Me.TradeType

and

Me!TradeType

Is there any?

Another question... when I want to set the values of the fields in the SQL
Server database under the application, should I do this by setting the value
of the field on the screen (ie, Me!TradeTypeCombo) or the current record (ie,
Me!TradeType), or should that make no difference at all?

My former code worked by getting the currentRecord, setting values in it,
then calling Update on it. This proved to be rather unstable though, the
application would randomly die on code that would run fine in other contexts.

I decided to rid myself of currentRecord after Don suggested I refer to
Me.whatever instead. Suddenly the app stabilized, and it ran faster too. So I
was pretty frustrated when it died on 2002 machines, which of course our
accountant has. Now I'm wondering if I correctly understood what Don said --
does Me.whatever really refer to the currentRecord? Or is that referring to
fields on the form only? Or either/both?

Maury
 
A

Albert D. Kallal

I have a question. What _exactly_ is the difference between...

Me.TradeType

and

Me!TradeType

Is there any?

-------------

Yes, the "." (dot) refers to methods and properties that are part of the
form. These typically are built in features.

The ! (bang) refers to user defined collections and values. Of course, they
often over lap. The other important factor is that "." values get resolved
at compile time, where as the "!" bang ones get resolved at runtime. This
is not really a performance issue, but if you have a form with abound
reocrdset, then you do NOT need to place the controls on the screen to
reference a value

So, me.ID or me!ID is will both work

However, if your code changes the recordsoruce at runtime, then a me.ID may
not exist anymore....(if you sql, or query for the form is changed).

So,
When you use me.ID, you will HAVE to put a control on the screen in order to
get at the value of me.ID (this is ONLY when you are setting the recordsouce
at runtime..and in fact no recordsouce is set when you start the form).
Further, you will instantly notice that the code can't compile unless you do
put a control called "id" on the screen when you don't have a reocrdosuce.

So, some actually prefer using the "dot", as it will NOT compile if you miss
type a field name, but in fact, the ! is more correct.

So, if the form is set to a table, or more the recommended a "query", then
the form inherits all the properties of the table, and thus you CAN as
mentioned used me.Fieldname. And, you can use me.Fieldname even if you don't
place a control on the form. However, this inheritance don't always work,
and of course if you set the forms reocrdset, then you can't resolve the
me.Fieldname at compile time. Often, if you change the query, or
table a form is attached to, you find some of your code might break.

So, the dot notation works for field names...but only due to the form
inheriting the properties of the table/query. Now, a form is consider a
"fixed" thing that you build. And, thus, if you put a control on the form
called ID, then in effect, this is a true member of the form (while YOU
created this member...it does belong to the form....so the rule of ! = user
stuff, and dot = built in stuff does get a bit confusing). However, just
think that once you permanently assign a query or table to a form, then it
permanently has all of the fields, and you can use me.

However, I often change the sql for a form, and specially more so for
a sub form. In this case, then I can't know if me.ID will work, and often
before I understood this stuff, I had to put a invisible control on the
form called me.id. If you use me!id, you don't every need that control
to actually be placed on the form.

So, if you are playing around with the reocrdsouce of a form, and you don't
have a correspond control on the screen then you then you CAN NOT use the
me.ID notation (at least reliability anyway) Thus, you have to use the user
defined notation of me!ID.

Often, to avoid any confusing here, a LOT of developers NEVER give the
control on the screen the same name as the underlying field in the
query/table
Thus, even if a control is NOT on the screen, you can always use
me!TheFieldName to
work with the data. And, to work with the control, one can ALWAYS use dot.

me.txtTheFieldName (or whatever naming convention you come up with).
Doing this will eliminate ALL confusing as to when you are referencing a
control. And, things really get nasty if you have a control with the same
name as a field, but set the datasouce to a different field! In fact, in
repots
I now very much avoided this, as they suffer MUCH when you have
controls and fields of the same name.

So, most of the time, you can use either..but the rule is for built in
features..you use "dot", and for your defneined values, you use !
Server database under the application, should I do this by setting the value
of the field on the screen (ie, Me!TradeTypeCombo) or the current record
(ie,
Me!TradeType), or should that make no difference at all?


Good question, now that I explained the difference. I would likely use
the me!TradeType to just set a value. However, since in fact you
DO expect the combo box to be on the screen, and you want it
to show all updates, then I would use the control name in this case.

And, you could even assume the control HAS to be on the screen, and
then you could even use the me. (dot). Thus, if you delete the control,
you code will now NOT compile anymore. So, you can use this to your
advantage.
On the other hand, since you might want to delete the control on eh screen
without
your code breaking..then again..you have to choose...

So, in your above example, if you need the
screen display to update..then use the control. And, the choice
between dot, and bang is this case is kind of up to you, and
your coding standards. For controls, I actually use the dot, but
this is a personal pref, and some would consider it not the best
choice. For all stuff like the "id" fields etc that don't show on the
form, I always now use the ! (bang). So, when you see a dot
notation in my code...I made the assuming that this is a control,
and it is on the screen....
 
A

Albert D. Kallal

I have a question. What _exactly_ is the difference between...

Me.TradeType

and

Me!TradeType

Is there any?

-------------

Yes, the "." (dot) referes to methods and properties that are part of the
form. These typically are built in features.

The ! (bang) references to user defined collections and values. Of course,
they
often over lap. The other important factor is that "." values get resolved
at compile time, where as the "!" bang ones get resolved at runtime. this
is not really a performance issue, but if you have a form with abound
reocrdset, then you do NOT need to place the controls on the screen to
reference a value

So, me.ID or me!ID is ok

However, if your code changes the recordsoruce at runtime, then a me.ID may
not exist anymore....

So,
When you use me.ID, you will HAVE to put a control on the screen in order to
get at the value of me.ID (this is ONLY when you are setting the recordsouce
at runtime..and in fact no recordsouce is set when you start the form).
Further, you will instantly notice that the code can't compile unless you do
put a control called "id" on the screen when you don't have a reocrdosuce.

So, some actually prefer using the "dot", as it will NOT compile if you miss
type a field name, but in fact, the ! is more correct.

So, if the form is set to a table, or more the recommended a "query", then
the form inherits all the properties of the table, and thus you CAN as
mentioned used me.Fieldname. And, you can use me.FieldName even if you don't
place a control on the form. However, this inheritance don't always work,
and of course if you set the forms reocrdset, then you can't resolve the
me.Fieldname at compile time.

So, the dot notation works for field names...but only due to the form
inheriting the properties of the table/query. Now, a form is consider a
"fixed" thing that you build. And, thus, if you put a control on the form
called ID, then in effect, this is a true member of the form (while YOU
created this member...it does belong to the form....so the rule of ! = user
stuff, and dot = built in stuff does get a bit confusing). However, no
matter what you do at runtime, the me.ID will always resolve to that control
on the screen. If you don't have that control on the screen, then you have
to use me!id.

So, if you are playing around with the reocrdsouce of a form, and you don't
have a correspond control on the screen then you then you can't use the
me.ID notation. Thus, you have to use the user defined notation of me!ID.

So, to prevent having to put a control on the screen to reference underlying
reocrdset data, you have to use the ! notation.

Often, to avoid any confusing here, a LOT of developers NEVER give the
control on the screen the same name as the underlying reocrdset. Thus, even
if a control is NOT on the screen, you can always use me!TheFieldName to
work with the data. And, to work with the control, one can use

me.txtTheFieldName (or whatever naming convention you come up with).
Doing this will eliminate ALL consuming as to when reference a control on
the
screen, or referencing a field of the underlying reocrdset of the form.

So, most of the time, you can use either..but the rule is for built in
features..you use "dot", and for your defined values, you use !
Server database under the application, should I do this by setting the value
of the field on the screen (ie, Me!TradeTypeCombo) or the current record
(ie,
Me!TradeType), or should that make no difference at all?

I would likely use the me!TradeType to just set a value. However, when
running code that is in a controls event...then I would use the control
name. (if you don't need anything to happen to the control..then use the
underlying ! notation) Since you ALSO have a contorl on the screen,
then then use the combo ref. So, in your above example, if you need the
screen display to update..then use the control.

You see, the combo box settings can actually display more then one column
etc, so if you need to get at those other columns, then you have to use the
combo control

I think for general issues of screen display, again I would
generally use the control on the screen. This can communicate
your intenstions as a devleoper. If you don't need the contorl on the
screen at all, then of course, then use the underyalig recordset ref of "!"
 
D

Dirk Goldgar

J. Clay said:
Another thing that I have found is rather than use the RunCommand use:

me.dirty = False

Just seems to work better for me.
Click to expand...

I like that and find it tidy, expressive, and specific (there's never
any doubt about which object is going to have its record saved), but it
has one flaw: if for some reason the record can't be saved, the error
message that you get refers to being unable to set a property, not being
unable to save a record. That can be confusing if you don't know what's
going on, so if you're using the Dirty property to save a record, you'd
better be sure you trap the error and present something more
comprehensible to the user.
 
D

david epsom dot com dot au

Maury Markowitz said:
I have a question. What _exactly_ is the difference between...

Me.TradeType

and

Me!TradeType

Is there any?
Click to expand...

If you invalidate the definition of .TradeType, you may
get a memory access error and a crash. If you invalidate
the definition of !TradeType, you will probably get a
run-time error message. So yes, there is a difference :~)


Access creates form 'properties' to match form fields and
controls. It ONLY does this in design mode. If you
programmatically change members of the fields collection
or of the controls collection, the 'property' does not get
updated. (These 'properties' are not members of the form
properties collection).

Me!TradeType refers to a control, so Me!TradeType probably refers
to a control.

When the form has a bound field with the same name as a control,
the property refers to the control.

If Me.TradeType refers to a field, then the bound recordset
needs to have a field with that name. If it doesn't, you
may get a nasty error.

(david)
 
Top