Funky Save Record Stuff

[Neil]

Was working in A2003 and noticed that the Save Record item on the Records
menu was not available when the record was not dirty. In A2000, Save Record
was always available. (This is a problem for me because I have Docmd.Runcmd
acCmdSaveRecord code all over the place, which never gave an error before.
But now it was giving an error when the Save Record menu command wasn't
available.)

So I went back to A2000 and confirmed that the Save Record menu command is
always available, whether the record is dirty or not. So I concluded this
was a change in A2003, that the menu item's only available when the record's
actually dirty.

However...... when I went back to A2003 and tested it again, I noticed that
it was acting in the same way as A2000, with the Save Record menu item
always available!

So, in summary:

In A2003, Save Record menu item was only available when record was actually
dirty (causing an error when docmd.runcmd accmdsaverecord was run when the
record was not dirty).

Went to A2000 and confirmed that the menu item was always available, whether
the record was dirty or not.

And when I returned to A2003, all of a sudden the menu item was always
available, as it is in A2000, though a few minutes before it had only been
available when the record was dirty!

So I was wondering if anyone else has noticed these shenanigans from A2003,
or has any idea what's going on, and why the funcationality would change
like that. Also, how does A2003 act in your copy: is the Save Record menu
item always available; or is it grayed out when the record's not dirty?

Thanks!

Neil

[Rich P]

Hi Neil,

Looking at this from a lower level programming standpoint - say
.Net/Java (where C++, MFC are real low level and the originating source
of .Net and Access/VBA) - Access/VBA is a very high level programming
platform and .Net is significantly lower. What this means is that
Access is heavily subclassed - contains a lot of built-in functionality
to accommodate the needs of a very wide range of users from beginners to
power users to developers. With this level of subclassing it is
inevitable that some inconsistencies will arise, and thus, at the
enterprise/corporate level - Access is not the ideal tool.

To illustrate a little further - .Net is significantly less subclassed
than Access. This means that there is a lot less built-in stuff, which
if the programmer needs something - like a continuous form which is not
built in to .Net - you have to create it yourself from scratch - but you
can do that in .Net because it is only a few notches more subclassed
than C++/MFC. Bottom line, the developer has way less control over the
more detailed aspects of programming in a high level (highly subclassed)
platform than the developer would in a lower level platform - .Net/Java.

Think of a power curve (if you are a math person). At the highest point
of the power curve (where the slope is zero, dy/dx = 0) you have max
power. If you proceed past that point - you are now behind the power
curve. Access was designed to ease programming for rapid application
development. And Access is, in fact, the fasted gun in the west - to a
point. Like a fighter plane - an F-16 is one of the most agile fighters
but would be useless against a missile battalion - for that you would
need some heavy bombers. Think of Access as the F16 and .Net/Java as
the heavy bombers. You can only write so much code for rapid
application development - but once you need more functionality - it is
time to go to a lower level platform.

Rich

*** Sent via Developersdex http://www.developersdex.com ***

[Lisa Moody]

Neil,

Do you see this in SP3 and not in SP2 when using MS Access 2003? I have
another situation previously posted about a problem with SP3 and my
developer is having trouble with Save Record when it's a memo field and
there is nothing in it. I am going to post that information in my previous
post, but it might be the same thing. It only happens when connecting via
ODBC to an SQL db and not when Access is the backend.

Lisa

"Neil" <no****@nospam. netwrote in message
news:kR******** ********@nlpi06 9.nbdc.sbc.com. ..

Was working in A2003 and noticed that the Save Record item on the Records
menu was not available when the record was not dirty. In A2000, Save
Record was always available. (This is a problem for me because I have
Docmd.Runcmd acCmdSaveRecord code all over the place, which never gave an
error before. But now it was giving an error when the Save Record menu
command wasn't available.)

So I went back to A2000 and confirmed that the Save Record menu command is
always available, whether the record is dirty or not. So I concluded this
was a change in A2003, that the menu item's only available when the
record's actually dirty.

However...... when I went back to A2003 and tested it again, I noticed
that it was acting in the same way as A2000, with the Save Record menu
item always available!

So, in summary:

In A2003, Save Record menu item was only available when record was
actually dirty (causing an error when docmd.runcmd accmdsaverecord was run
when the record was not dirty).

Went to A2000 and confirmed that the menu item was always available,
whether the record was dirty or not.

And when I returned to A2003, all of a sudden the menu item was always
available, as it is in A2000, though a few minutes before it had only been
available when the record was dirty!

So I was wondering if anyone else has noticed these shenanigans from
A2003, or has any idea what's going on, and why the funcationality would
change like that. Also, how does A2003 act in your copy: is the Save
Record menu item always available; or is it grayed out when the record's
not dirty?

Thanks!

Neil

[Lisa Moody]

Here is what I posted in my other thread and it might apply for this also:

The problem appears to be with the way updated Access handles the empty
string (""). Specifically with Memo type fields mapped to ODBC SQL
connections of LONG VARCHAR type. In previous versions of Access, the empty
string would be passed to the SQL back end as a Null. This works great
because text boxes don't accept Null as a value, so if the text box was
empty, the empty string could be passed via a RunSQL command just like any
other string and it would be translated to Null in the back end data source.
Now, we have to add exception handling for zero length strings. This is
probably a side effect of a fix or could have been determined to be a
security hole. Either way it's causing rework and I didn't find any
documentation for the change.

The catch is that having the code add a space to the field doesn't make it
dirty "enough?" and doesn't solve our immediate need.

Lisa
"Lisa Moody" <lm****@jewelco de.comwrote in message
news:CK******** *************** *******@comcast .com...

Neil,

Do you see this in SP3 and not in SP2 when using MS Access 2003? I have
another situation previously posted about a problem with SP3 and my
developer is having trouble with Save Record when it's a memo field and
there is nothing in it. I am going to post that information in my
previous post, but it might be the same thing. It only happens when
connecting via ODBC to an SQL db and not when Access is the backend.

Lisa

"Neil" <no****@nospam. netwrote in message
news:kR******** ********@nlpi06 9.nbdc.sbc.com. ..

>Was working in A2003 and noticed that the Save Record item on the Records
menu was not available when the record was not dirty. In A2000, Save
Record was always available. (This is a problem for me because I have
Docmd.Runcmd acCmdSaveRecord code all over the place, which never gave an
error before. But now it was giving an error when the Save Record menu
command wasn't available.)

So I went back to A2000 and confirmed that the Save Record menu command
is always available, whether the record is dirty or not. So I concluded
this was a change in A2003, that the menu item's only available when the
record's actually dirty.

However..... . when I went back to A2003 and tested it again, I noticed
that it was acting in the same way as A2000, with the Save Record menu
item always available!

So, in summary:

In A2003, Save Record menu item was only available when record was
actually dirty (causing an error when docmd.runcmd accmdsaverecord was
run when the record was not dirty).

Went to A2000 and confirmed that the menu item was always available,
whether the record was dirty or not.

And when I returned to A2003, all of a sudden the menu item was always
available, as it is in A2000, though a few minutes before it had only
been available when the record was dirty!

So I was wondering if anyone else has noticed these shenanigans from
A2003, or has any idea what's going on, and why the funcationality would
change like that. Also, how does A2003 act in your copy: is the Save
Record menu item always available; or is it grayed out when the record's
not dirty?

Thanks!

Neil

[Linq Adams via AccessMonster.com]

>So, in summary:

>In A2003, Save Record menu item was only available when record was actually
dirty (causing an error when docmd.runcmd accmdsaverecord was run when the
record was not dirty).

>Went to A2000 and confirmed that the menu item was always available, whether
the record was dirty or not.

>And when I returned to A2003, all of a sudden the menu item was always
available, as it is in A2000, though a few minutes before it had only been
available when the record was dirty!"

This sounds suspiciously like a case of $hit happens!

--
There's ALWAYS more than one way to skin a cat!

Answers/posts based on Access 2000/2003

Message posted via AccessMonster.c om
http://www.accessmonster.com/Uwe/For...ccess/200804/1

[Neil]

I am using SP3, so I don't know about SP2. And, yes, mine is a SQL Server
backend (via ODBC) as well. Whatever happened (with Save Record not being
available in a non-dirty record), it cleared itself after going to A2000 and
then back to A2003 again. But the version of Access I'm using was the same
in both cases.

"Lisa Moody" <lm****@jewelco de.comwrote in message
news:CK******** *************** *******@comcast .com...

Neil,

Do you see this in SP3 and not in SP2 when using MS Access 2003? I have
another situation previously posted about a problem with SP3 and my
developer is having trouble with Save Record when it's a memo field and
there is nothing in it. I am going to post that information in my
previous post, but it might be the same thing. It only happens when
connecting via ODBC to an SQL db and not when Access is the backend.

Lisa

"Neil" <no****@nospam. netwrote in message
news:kR******** ********@nlpi06 9.nbdc.sbc.com. ..

>Was working in A2003 and noticed that the Save Record item on the Records
menu was not available when the record was not dirty. In A2000, Save
Record was always available. (This is a problem for me because I have
Docmd.Runcmd acCmdSaveRecord code all over the place, which never gave an
error before. But now it was giving an error when the Save Record menu
command wasn't available.)

So I went back to A2000 and confirmed that the Save Record menu command
is always available, whether the record is dirty or not. So I concluded
this was a change in A2003, that the menu item's only available when the
record's actually dirty.

However..... . when I went back to A2003 and tested it again, I noticed
that it was acting in the same way as A2000, with the Save Record menu
item always available!

So, in summary:

In A2003, Save Record menu item was only available when record was
actually dirty (causing an error when docmd.runcmd accmdsaverecord was
run when the record was not dirty).

Went to A2000 and confirmed that the menu item was always available,
whether the record was dirty or not.

And when I returned to A2003, all of a sudden the menu item was always
available, as it is in A2000, though a few minutes before it had only
been available when the record was dirty!

So I was wondering if anyone else has noticed these shenanigans from
A2003, or has any idea what's going on, and why the funcationality would
change like that. Also, how does A2003 act in your copy: is the Save
Record menu item always available; or is it grayed out when the record's
not dirty?

Thanks!

Neil

[Neil]

Lisa,

I'm not experiencing this problem. But, first, I never heard of Long
Varchar. I've heard of varchar and nvarchar. Are you referring to nvarchar?

Second, I'm not following what your problem is. You're trying to store an
empty string in a memo field and it's not getting converted to Null? Maybe
you can elaborate.
"Lisa Moody" <lm****@jewelco de.comwrote in message
news:-9************** *************** *@comcast.com.. .

Here is what I posted in my other thread and it might apply for this also:

The problem appears to be with the way updated Access handles the empty
string (""). Specifically with Memo type fields mapped to ODBC SQL
connections of LONG VARCHAR type. In previous versions of Access, the
empty string would be passed to the SQL back end as a Null. This works
great because text boxes don't accept Null as a value, so if the text box
was empty, the empty string could be passed via a RunSQL command just like
any other string and it would be translated to Null in the back end data
source. Now, we have to add exception handling for zero length strings.
This is probably a side effect of a fix or could have been determined to
be a security hole. Either way it's causing rework and I didn't find any
documentation for the change.

The catch is that having the code add a space to the field doesn't make it
dirty "enough?" and doesn't solve our immediate need.

Lisa
"Lisa Moody" <lm****@jewelco de.comwrote in message
news:CK******** *************** *******@comcast .com...

>Neil,

Do you see this in SP3 and not in SP2 when using MS Access 2003? I have
another situation previously posted about a problem with SP3 and my
developer is having trouble with Save Record when it's a memo field and
there is nothing in it. I am going to post that information in my
previous post, but it might be the same thing. It only happens when
connecting via ODBC to an SQL db and not when Access is the backend.

Lisa

"Neil" <no****@nospam. netwrote in message
news:kR******* *********@nlpi0 69.nbdc.sbc.com ...

>>Was working in A2003 and noticed that the Save Record item on the
Records menu was not available when the record was not dirty. In A2000,
Save Record was always available. (This is a problem for me because I
have Docmd.Runcmd acCmdSaveRecord code all over the place, which never
gave an error before. But now it was giving an error when the Save
Record menu command wasn't available.)

So I went back to A2000 and confirmed that the Save Record menu command
is always available, whether the record is dirty or not. So I concluded
this was a change in A2003, that the menu item's only available when the
record's actually dirty.

However.... .. when I went back to A2003 and tested it again, I noticed
that it was acting in the same way as A2000, with the Save Record menu
item always available!

So, in summary:

In A2003, Save Record menu item was only available when record was
actually dirty (causing an error when docmd.runcmd accmdsaverecord was
run when the record was not dirty).

Went to A2000 and confirmed that the menu item was always available,
whether the record was dirty or not.

And when I returned to A2003, all of a sudden the menu item was always
available, as it is in A2000, though a few minutes before it had only
been available when the record was dirty!

So I was wondering if anyone else has noticed these shenanigans from
A2003, or has any idea what's going on, and why the funcationality would
change like that. Also, how does A2003 act in your copy: is the Save
Record menu item always available; or is it grayed out when the record's
not dirty?

Thanks!

Neil

[Neil]

"Linq Adams via AccessMonster.c om" <u28780@uwewrot e in message
news:82b1fe2ecc 3be@uwe...

So, in summary:

>>In A2003, Save Record menu item was only available when record was
actually
dirty (causing an error when docmd.runcmd accmdsaverecord was run when the
record was not dirty).

>>Went to A2000 and confirmed that the menu item was always available,
whether
the record was dirty or not.

>>And when I returned to A2003, all of a sudden the menu item was always
available, as it is in A2000, though a few minutes before it had only been
available when the record was dirty!"

This sounds suspiciously like a case of $hit happens!

Well, that's fine. As long as A2003 works the same as A2000 in this regard,
I'll chalk it up to a hiccup. Can you confirm that the Save Record command
is available for you in A2003, even when the record's not dirty?

Thanks!

Neil