Access 2003

I have a client who is using Access 2002/2000 (the database itself is
written in 2000), and is considering migrating to Access 2003. Any
recommendations on whether Access 2003 is worth the migrate, or should he
stick with 2002?

Thanks!

Neil

re: Access 2003

If you are going to upgrade, I would go to 2003, not 2002. The help files
are definately better in 2003 than 2000 or 2002. There are some other nice
features added. The 2000 field format is still the default and the 2002 file
format is now the 2002/2003 format. Here is more information on new
features.

http://support.microsoft.com/default...roduct=acc2003

--
Wayne Morgan
MS Access MVP


"Neil Ginsberg" <news@nrgconsult.com> wrote in message
news:NX3uc.16072$be.9074@newsread2.news.pas.earthl ink.net...[color=blue]
> I have a client who is using Access 2002/2000 (the database itself is
> written in 2000), and is considering migrating to Access 2003. Any
> recommendations on whether Access 2003 is worth the migrate, or should he
> stick with 2002?[/color]

re: Access 2003

"Wayne Morgan" wrote
[color=blue]
> If you are going to upgrade, I would go to
> 2003, not 2002. The help files are definately
> better in 2003 than 2000 or 2002.[/color]

I respectfully disagree -- the _content_ of the Help files has been somewhat
(but IMNSHO only somewhat) improved, but the user interface to help is an
abomination. The better content is useless if you cannot easily get to it.
[color=blue]
> There are some other nice
> features added.[/color]

My observation is that there were few, very, very few, Access-specific
changes between Access 2002-2003, and that the bulk of the changes were
Office-wide improvements to collaboration features aimed at the corporate
enterprise environment.

If you are not in the corporate enterprise environment (in which case, your
dedicated Microsoft marketing team will be making the case with your IT or
corporate management to upgrade), then I see very little reason to upgrade
from Office 2002 to Office 2003 System. Either would be an improvement over
Access 2000, even if you have all three of Access 2000's Service Packs
installed. (Sadly, I am doing some work for one client on a system using
Access 2000 that only has SP-1 installed; fortunately, it has only possibly
one time "bit me in the tender places", corrupting and losing access to a
Form.)

And, if I understood the original post, the upgrade would be from Access
2002 (Office XP) to Access 2003 (Office 2003 System), so my advice would be,
"Don't waste your time and energy." If all the users have Access 2002, I
don't see any advantage in saving your DB in Access 2000 format.

Larry Linson
Microsoft Access MVP

re: Access 2003

> And, if I understood the original post, the upgrade would be from Access[color=blue]
> 2002 (Office XP) to Access 2003 (Office 2003 System), so my advice would[/color]
be,[color=blue]
> "Don't waste your time and energy." If all the users have Access 2002, I
> don't see any advantage in saving your DB in Access 2000 format.[/color]

Hi, Larry.

Actually, about half the users have A2000, and the other half have A2002.
Perhaps more significantly, the db itself is written in A2000, and I'm using
A2000 (as the sole developer). So going to A2003 would be significant in
that it would unify the version (though some may stay at 2002, I suppose)
and would upgrade the development version, itself.

On another note, another client of mine is looking to convert an MDB front
end with ODBC links to SQL Server 7.0 to an ADP file. Any thoughts on that,
both in general, and in regard to A2003?

Thanks,

Neil
By the way, have you tried the new Buffet Grapevine up on W.D. Tate? It
looks like a dive, but it's a pretty decent Chinese buffet.

re: Access 2003

On Sat, 29 May 2004 20:29:43 GMT, "Neil Ginsberg" <news@nrgconsult.com> wrote:
[color=blue][color=green]
>> And, if I understood the original post, the upgrade would be from Access
>> 2002 (Office XP) to Access 2003 (Office 2003 System), so my advice would[/color]
>be,[color=green]
>> "Don't waste your time and energy." If all the users have Access 2002, I
>> don't see any advantage in saving your DB in Access 2000 format.[/color]
>
>Hi, Larry.
>
>Actually, about half the users have A2000, and the other half have A2002.
>Perhaps more significantly, the db itself is written in A2000, and I'm using
>A2000 (as the sole developer). So going to A2003 would be significant in
>that it would unify the version (though some may stay at 2002, I suppose)
>and would upgrade the development version, itself.
>
>On another note, another client of mine is looking to convert an MDB front
>end with ODBC links to SQL Server 7.0 to an ADP file. Any thoughts on that,
>both in general, and in regard to A2003?[/color]

You'll get some other opinions that disagree with mine here, but I've been
working on an ADP project for the last year, and I'm thinking it might be
worth the effort to convert the whole thing to an MDB. I -might- consider
starting a new project as an ADP if all the stars were aligned just right, but
I would never in my wildest dreams think I should convert an existing, working
MDB application to an ADP.

Using an MDB as a front-end to SQL Server does require some work-arounds that
are not required in an ADP, but these work-arounds are well known, and well
described in a lot of places. On the other hand, I spend a large part of each
day working on an ADP application working around bugs in the ADP
implementation itself. There is also net performance gain with ADPs since
they make many more requests from the server to handle the excessively tight
integration with the server back-end.

re: Access 2003

Correction...
[color=blue]
>implementation itself. There is also net performance gain with ADPs since
>they make many more requests from the server to handle the excessively tight
>integration with the server back-end.[/color]

Should read - "There is also -no- net performance gain ..."

re: Access 2003

Neil Ginsberg wrote:
[color=blue][color=green]
>>And, if I understood the original post, the upgrade would be from Access
>>2002 (Office XP) to Access 2003 (Office 2003 System), so my advice would[/color]
>
> be,
>[color=green]
>>"Don't waste your time and energy." If all the users have Access 2002, I
>>don't see any advantage in saving your DB in Access 2000 format.[/color]
>
>
> Hi, Larry.
>
> Actually, about half the users have A2000, and the other half have A2002.
> Perhaps more significantly, the db itself is written in A2000, and I'm using
> A2000 (as the sole developer). So going to A2003 would be significant in
> that it would unify the version (though some may stay at 2002, I suppose)
> and would upgrade the development version, itself.[/color]

A2003 requires Win2000 or WinXP OS, does not run on NT or 98. Make sure
all of your users have that OS running before you do a mass migration to it.
[color=blue]
>
> On another note, another client of mine is looking to convert an MDB front
> end with ODBC links to SQL Server 7.0 to an ADP file. Any thoughts on that,
> both in general, and in regard to A2003?
>
> Thanks,
>
> Neil
> By the way, have you tried the new Buffet Grapevine up on W.D. Tate? It
> looks like a dive, but it's a pretty decent Chinese buffet.
>
>[/color]

re: Access 2003

Larry Linson wrote:
[color=blue]
> "Wayne Morgan" wrote
>[color=green]
> > If you are going to upgrade, I would go to
> > 2003, not 2002. The help files are definately
> > better in 2003 than 2000 or 2002.[/color]
>
> I respectfully disagree -- the _content_ of the Help files has been somewhat
> (but IMNSHO only somewhat) improved, but the user interface to help is an
> abomination. The better content is useless if you cannot easily get to it.[/color]

I wonder if anyone has told MS that their help files are the worst in
the industry or if they sit around and slap each other on that back and
share high-5s for their abomination.

re: Access 2003

"Larry Linson" <bouncer@localhost.not> wrote in
news:3f5uc.7619$oh7.6798@nwrddc01.gnilink.net:
[color=blue]
> Sadly, I am doing some work for one client on a system using
> Access 2000 that only has SP-1 installed; fortunately, it has only
> possibly one time "bit me in the tender places", corrupting and
> losing access to a Form.[/color]

I don't have any such issues with A2K running on SR1a.

Because of the Dranconian security patches to Outlook that were
rolled out in SR2 and beyond, I won't apply anything but SR1a.

And no corruption.

So far as my experience with A2K runs, SR1a+ and SP6+ is all that's
required to get a usable version of A2K.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

re: Access 2003

On Sat, 29 May 2004 21:44:46 GMT, "David W. Fenton"
<dXXXfenton@bway.net.invalid> wrote:

By the way, if you are in an Exchange environment, you can add this to
the registry:
[HKEY_CURRENT_USER\Software\Policies\Microsoft\Secu rity]
"CheckAdminSettings"=dword:00000001

and then use the special security form (soory, the exact name escapes
me now) in the public folder tree to adjust the security checks to
more normal settings.

A client must have a REALLY good reason not to go with the latest
versions from Windows Update. With all variety of machines out there,
the client being able to proscribe (often ill-informed) outdated
platforms is a variable I don't really want to deal with.

-Tom.

[color=blue]
>"Larry Linson" <bouncer@localhost.not> wrote in
>news:3f5uc.7619$oh7.6798@nwrddc01.gnilink.net:
>[color=green]
>> Sadly, I am doing some work for one client on a system using
>> Access 2000 that only has SP-1 installed; fortunately, it has only
>> possibly one time "bit me in the tender places", corrupting and
>> losing access to a Form.[/color]
>
>I don't have any such issues with A2K running on SR1a.
>
>Because of the Dranconian security patches to Outlook that were
>rolled out in SR2 and beyond, I won't apply anything but SR1a.
>
>And no corruption.
>
>So far as my experience with A2K runs, SR1a+ and SP6+ is all that's
>required to get a usable version of A2K.[/color]

re: Access 2003

If I had the option in your/your client's case, I might grit my teeth and
move everyone to Access 2003 -- but, IF and ONLY IF, all users had an
always-on high-speed Internet connection. The default for Access 2003 Help,
the first place they take you, is Online Help. Since they could not index
every bit of Access-help-type information at the Microsoft site, the very
useful Index tab in Help is no longer there.

I have no complaints about the software itself... it's as good as, or a
miniscule bit better than, Access 2002. And, I am told, the Help content has
been improved (but I am not certain they weren't just talking about "the
vast amount of help information available online" -- and, even with a
high-speed, always-on Internet connection, I have trouble finding things
that were easy to find in the past).

There was so little Access-specific enhancement that it can be ignored. I'd
have to have a client with specific needs for corporate, enterprise
collaboration features to get excited about Access 2003.

On this notebook computer that I use for personal and business, I have
Access 97, Access 2002, and Access 2003. Access 97 is there because some
clients don't want to move beyond it (and I wouldn't try to convince them
otherwise, as 97 handles their needs very nicely -- it's out of support, but
they haven't needed any Microsoft support in a long, long time) and for the
excellent WinHelp interface; Access 2002 is the one I am using most often
now, just because its HTML Help is so much easier to use than Access 2003's
"new help", and I have yet to have any problems because some
feature/function is missing that would be in Access 2003.

Yes, I have tried it and thought it OK... but my long-time favorite is a
much smaller, very friendly Chinese buffet, now called Tai-Pan, in the
shopping center behind it. If you give it a try, tell Eric that Larry Linson
sent you.

Larry Linson
Microsoft Access MVP

re: Access 2003

Tom van Stiphout <tom7744@no.spam.cox.net> wrote in
news:pt9ib096g4icorse724qf0k6gqn5muoqb5@4ax.com:
[color=blue]
> A client must have a REALLY good reason not to go with the latest
> versions from Windows Update. With all variety of machines out
> there, the client being able to proscribe (often ill-informed)
> outdated platforms is a variable I don't really want to deal with.[/color]

Well, we'll have to agree to disagree on this one.

I've made many 100s of dollars rescuing systems from Windows Update
fiascos, so I won't let my clients use Windows Update unsupervised.

Of course, for the clients where I have a say in the matter, they
don't use Outlook as email client, in any case, since I consider it
by far the worst email client I've ever encountered.

But I don't have a say for many of them, and in those cases, I will
not be recommending a service release level that will be changing
other applications in ways that are not easily recovered from.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

re: Access 2003

Salad <oil@vinegar.com> wrote in
news:Yq7uc.15085$Tn6.2747@newsread1.news.pas.earth link.net:
[color=blue]
> I wonder if anyone has told MS that their help files are the worst
> in the industry or if they sit around and slap each other on that
> back and share high-5s for their abomination.[/color]

The ridiculous thing about it is that the Access 97 help files are
by far the best help files I've used in any application, bar none.

And the content of the A2K help files is virtually identical.

The problems are entirely in the new UI, not in the actual content.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

re: Access 2003

That's very interesting. I was not aware of the bugs in the ADP file, nor
that there were no net performance gains. I thought the opposite would be
the case, especially since ADO has been around for a while now and has had a
chance to mature (but I guess it hasn't?).

The MDB that I set up is for the most part working fine. Where pass-throughs
and stored procedures are used, there are no problems (though sometimes it
requires a bit of a workaround, since pass-throughs aren't editable).

The main problems we've been having have been with the bound forms that we
use for viewing and editing, which use ODBC linked tables. I set up a
standard view/edit configuration, where the form opens in "view mode" bound
to a pass-through query, and then the user clicks Edit and they get an
editable recordset based on a linked table. This has worked OK; but we have
a lot of locking issues. Sometimes a table gets locked and can't be updated,
even though the only place where another user could be accessing the record
is in the list portion of a combo box! So it's been somewhat perplexing and
difficult to track down the source of this locking problem (though,
forturnately, it doesn't happen frequently, and not with all tables).

So it's a series of little problems such as this that got us leaning towards
an ADP, thinking that would resolve the problem. But the db is pretty solid
otherwise. So maybe it's best to leave well enough alone.....

Any other thoughts?

Thanks,

Neil


"Steve Jorgensen" <nospam@nospam.nospam> wrote in message
news:prthb0tt8s6ns2uuetlpeas33m4vbtkf7l@4ax.com...[color=blue]
> On Sat, 29 May 2004 20:29:43 GMT, "Neil Ginsberg" <news@nrgconsult.com>[/color]
wrote:[color=blue]
>[color=green][color=darkred]
> >> And, if I understood the original post, the upgrade would be from[/color][/color][/color]
Access[color=blue][color=green][color=darkred]
> >> 2002 (Office XP) to Access 2003 (Office 2003 System), so my advice[/color][/color][/color]
would[color=blue][color=green]
> >be,[color=darkred]
> >> "Don't waste your time and energy." If all the users have Access 2002,[/color][/color][/color]
I[color=blue][color=green][color=darkred]
> >> don't see any advantage in saving your DB in Access 2000 format.[/color]
> >
> >Hi, Larry.
> >
> >Actually, about half the users have A2000, and the other half have A2002.
> >Perhaps more significantly, the db itself is written in A2000, and I'm[/color][/color]
using[color=blue][color=green]
> >A2000 (as the sole developer). So going to A2003 would be significant in
> >that it would unify the version (though some may stay at 2002, I suppose)
> >and would upgrade the development version, itself.
> >
> >On another note, another client of mine is looking to convert an MDB[/color][/color]
front[color=blue][color=green]
> >end with ODBC links to SQL Server 7.0 to an ADP file. Any thoughts on[/color][/color]
that,[color=blue][color=green]
> >both in general, and in regard to A2003?[/color]
>
> You'll get some other opinions that disagree with mine here, but I've been
> working on an ADP project for the last year, and I'm thinking it might be
> worth the effort to convert the whole thing to an MDB. I -might- consider
> starting a new project as an ADP if all the stars were aligned just right,[/color]
but[color=blue]
> I would never in my wildest dreams think I should convert an existing,[/color]
working[color=blue]
> MDB application to an ADP.
>
> Using an MDB as a front-end to SQL Server does require some work-arounds[/color]
that[color=blue]
> are not required in an ADP, but these work-arounds are well known, and[/color]
well[color=blue]
> described in a lot of places. On the other hand, I spend a large part of[/color]
each[color=blue]
> day working on an ADP application working around bugs in the ADP
> implementation itself. There is also net performance gain with ADPs since
> they make many more requests from the server to handle the excessively[/color]
tight[color=blue]
> integration with the server back-end.[/color]

re: Access 2003

Sounds like it would be best to leave well-enough alone, but maybe move the
2000 users (as well as the development version) to 2002 (though maybe that's
not even necessary).

I looked up Tai-Pan at Yahoo Yellow Pages, and didn't see anything. What was
their old name? I don't recall seeing another Chinese place in the
Target/Starbuck's/Jason's Deli shopping center (I presume that's the one
you're referring to).

Neil

"Larry Linson" <bouncer@localhost.not> wrote in message
news:Wvduc.9385$oh7.5584@nwrddc01.gnilink.net...[color=blue]
> If I had the option in your/your client's case, I might grit my teeth and
> move everyone to Access 2003 -- but, IF and ONLY IF, all users had an
> always-on high-speed Internet connection. The default for Access 2003[/color]
Help,[color=blue]
> the first place they take you, is Online Help. Since they could not index
> every bit of Access-help-type information at the Microsoft site, the very
> useful Index tab in Help is no longer there.
>
> I have no complaints about the software itself... it's as good as, or a
> miniscule bit better than, Access 2002. And, I am told, the Help content[/color]
has[color=blue]
> been improved (but I am not certain they weren't just talking about "the
> vast amount of help information available online" -- and, even with a
> high-speed, always-on Internet connection, I have trouble finding things
> that were easy to find in the past).
>
> There was so little Access-specific enhancement that it can be ignored.[/color]
I'd[color=blue]
> have to have a client with specific needs for corporate, enterprise
> collaboration features to get excited about Access 2003.
>
> On this notebook computer that I use for personal and business, I have
> Access 97, Access 2002, and Access 2003. Access 97 is there because some
> clients don't want to move beyond it (and I wouldn't try to convince them
> otherwise, as 97 handles their needs very nicely -- it's out of support,[/color]
but[color=blue]
> they haven't needed any Microsoft support in a long, long time) and for[/color]
the[color=blue]
> excellent WinHelp interface; Access 2002 is the one I am using most often
> now, just because its HTML Help is so much easier to use than Access[/color]
2003's[color=blue]
> "new help", and I have yet to have any problems because some
> feature/function is missing that would be in Access 2003.
>
> Yes, I have tried it and thought it OK... but my long-time favorite is a
> much smaller, very friendly Chinese buffet, now called Tai-Pan, in the
> shopping center behind it. If you give it a try, tell Eric that Larry[/color]
Linson[color=blue]
> sent you.
>
> Larry Linson
> Microsoft Access MVP
>
>[/color]

re: Access 2003

On Sun, 30 May 2004 23:33:41 GMT, "Neil Ginsberg" <news@nrgconsult.com> wrote:
[color=blue]
>That's very interesting. I was not aware of the bugs in the ADP file, nor
>that there were no net performance gains. I thought the opposite would be
>the case, especially since ADO has been around for a while now and has had a
>chance to mature (but I guess it hasn't?).[/color]

It should have had a chance to mature, but Microsoft doesn't seem to be
focusing one iota of energy on it, perhaps because hardly anyone ever liked it
enough to use it.
[color=blue]
>The MDB that I set up is for the most part working fine. Where pass-throughs
>and stored procedures are used, there are no problems (though sometimes it
>requires a bit of a workaround, since pass-throughs aren't editable).
>
>The main problems we've been having have been with the bound forms that we
>use for viewing and editing, which use ODBC linked tables. I set up a
>standard view/edit configuration, where the form opens in "view mode" bound
>to a pass-through query, and then the user clicks Edit and they get an
>editable recordset based on a linked table. This has worked OK; but we have
>a lot of locking issues. Sometimes a table gets locked and can't be updated,
>even though the only place where another user could be accessing the record
>is in the list portion of a combo box! So it's been somewhat perplexing and
>difficult to track down the source of this locking problem (though,
>forturnately, it doesn't happen frequently, and not with all tables).[/color]

These problems exist in ADPs, too, and the cause/solution is the same. Both
ADO and DAO use optimistic locking for updating server-side data, and this
relies on comparing the pre-edit data to the data currently on the server. If
the table contains real number fields or dates with fractional seconds, the
compare may fail even though nothing has changed. The trick is to avoid using
those data types. Use the Currency (MONEY) type for fractional numbers.
[color=blue]
>So it's a series of little problems such as this that got us leaning towards
>an ADP, thinking that would resolve the problem. But the db is pretty solid
>otherwise. So maybe it's best to leave well enough alone.....[/color]

Keep in in an MDB - you won't be sorry. Keep posting here with the problems
you're running into, and we'll help provide you with the nicest workarounds.

re: Access 2003

> On Sun, 30 May 2004 23:33:41 GMT, "Neil Ginsberg" <news@nrgconsult.com>[color=blue]
> wrote:
>[color=green]
>>That's very interesting. I was not aware of the bugs in the ADP file,
>>nor that there were no net performance gains.[/color][/color]

You might wish to canvass those of us who work regularly with ADPs before you
write them off. I have delivered several ADP applications over the past ...
hmmm ... 4? ... years, to a large company in Atlanta, to a proefessional
organization in Washington, and to several educational institutions. I have
not found any insurmountable problems with ADPs. My clients are at least as
happy as they have been previously with MDBs, FoxPro, Foxbase, Clipper and
DBaseIII.
It's unlikely that I will be using MDBs for any major application in the
future. The power of T-SQL and MS-SQL Server, and the superior backup,
security and protection from corruption of the latter, and the seamless
interface provided by ADPs create, in my opinion an almost ideal RAD
platform.

--
Lyle
(for e-mail refer to http://ffdba.com/contacts.htm)

re: Access 2003

"Lyle Fairfield" wrote
[color=blue]
> You might wish to canvass those of us who
> work regularly with ADPs before you write
> them off. I have . . . I have not found any in-
> surmountable problems with ADPs.[/color]

Did you, previously, find any insurmountable problems with MDBs as clients
for Microsoft SQL Server? I have not, over the years, using
MDB-Jet-ODBC-server.
[color=blue]
> It's unlikely that I will be using MDBs for any
> major application in the future. The power of
> T-SQL and MS-SQL Server, and the superior
> backup, security and protection from corruption
> of the latter, and the seamless interface provided
> by ADPs create, in my opinion an almost ideal RAD
> platform.[/color]

You write as though the only way to use MS-SQL Server were with an ADP --
which is certainly not the case.

I certainly have observed no automatic, inherent performance advantage of
ADP over MDB (and have heard from others whose opinion I trust that they
have done testing that did not indicate any). That has recently been
confirmed, BTW, by knowledgeable Microsoft insiders.

And, finally, I agree with Steve that Microsoft seems to have lost interest
in ADP... they addressed some problems in Service Releases to Access 2000
and in the work that went into Access 2002, but nothing since that I've
heard about.

Larry

re: Access 2003

"Neil Ginsberg" wrote
[color=blue]
> I looked up Tai-Pan at Yahoo Yellow Pages,
> and didn't see anything. What was their old
> name?[/color]

China Grill.
[color=blue]
> I don't recall seeing another Chinese
> place in the Target/Starbuck's/Jason's
> Deli shopping center (I presume that's
> the one you're referring to).[/color]

It's a couple of doors toward the street from the Subway, just around the
corner from where Esparza's Too used to be.

re: Access 2003

So you would agree with Steve's recommendation to me re. not converting to
ADP?

Neil

"Larry Linson" <bouncer@localhost.not> wrote in message
news:pRwuc.11918$oh7.4555@nwrddc01.gnilink.net...[color=blue]
> "Lyle Fairfield" wrote
>[color=green]
> > You might wish to canvass those of us who
> > work regularly with ADPs before you write
> > them off. I have . . . I have not found any in-
> > surmountable problems with ADPs.[/color]
>
> Did you, previously, find any insurmountable problems with MDBs as clients
> for Microsoft SQL Server? I have not, over the years, using
> MDB-Jet-ODBC-server.
>[color=green]
> > It's unlikely that I will be using MDBs for any
> > major application in the future. The power of
> > T-SQL and MS-SQL Server, and the superior
> > backup, security and protection from corruption
> > of the latter, and the seamless interface provided
> > by ADPs create, in my opinion an almost ideal RAD
> > platform.[/color]
>
> You write as though the only way to use MS-SQL Server were with an ADP --
> which is certainly not the case.
>
> I certainly have observed no automatic, inherent performance advantage of
> ADP over MDB (and have heard from others whose opinion I trust that they
> have done testing that did not indicate any). That has recently been
> confirmed, BTW, by knowledgeable Microsoft insiders.
>
> And, finally, I agree with Steve that Microsoft seems to have lost[/color]
interest[color=blue]
> in ADP... they addressed some problems in Service Releases to Access 2000
> and in the work that went into Access 2002, but nothing since that I've
> heard about.
>
> Larry
>
>[/color]

re: Access 2003

You'd think they'd provide some way to control the type of locking they use.
Too much trouble I guess.

Anyway, you're saying to avoid using Float data type -- even DateTime type
(??) -- and use Currency instead?

Neil


"Steve Jorgensen" <nospam@nospam.nospam> wrote in message
news:qutkb01fh8hv02vkvbmkhdptsprfh10eqa@4ax.com...[color=blue]
> On Sun, 30 May 2004 23:33:41 GMT, "Neil Ginsberg" <news@nrgconsult.com>[/color]
wrote:[color=blue]
>[color=green]
> >That's very interesting. I was not aware of the bugs in the ADP file, nor
> >that there were no net performance gains. I thought the opposite would be
> >the case, especially since ADO has been around for a while now and has[/color][/color]
had a[color=blue][color=green]
> >chance to mature (but I guess it hasn't?).[/color]
>
> It should have had a chance to mature, but Microsoft doesn't seem to be
> focusing one iota of energy on it, perhaps because hardly anyone ever[/color]
liked it[color=blue]
> enough to use it.
>[color=green]
> >The MDB that I set up is for the most part working fine. Where[/color][/color]
pass-throughs[color=blue][color=green]
> >and stored procedures are used, there are no problems (though sometimes[/color][/color]
it[color=blue][color=green]
> >requires a bit of a workaround, since pass-throughs aren't editable).
> >
> >The main problems we've been having have been with the bound forms that[/color][/color]
we[color=blue][color=green]
> >use for viewing and editing, which use ODBC linked tables. I set up a
> >standard view/edit configuration, where the form opens in "view mode"[/color][/color]
bound[color=blue][color=green]
> >to a pass-through query, and then the user clicks Edit and they get an
> >editable recordset based on a linked table. This has worked OK; but we[/color][/color]
have[color=blue][color=green]
> >a lot of locking issues. Sometimes a table gets locked and can't be[/color][/color]
updated,[color=blue][color=green]
> >even though the only place where another user could be accessing the[/color][/color]
record[color=blue][color=green]
> >is in the list portion of a combo box! So it's been somewhat perplexing[/color][/color]
and[color=blue][color=green]
> >difficult to track down the source of this locking problem (though,
> >forturnately, it doesn't happen frequently, and not with all tables).[/color]
>
> These problems exist in ADPs, too, and the cause/solution is the same.[/color]
Both[color=blue]
> ADO and DAO use optimistic locking for updating server-side data, and this
> relies on comparing the pre-edit data to the data currently on the server.[/color]
If[color=blue]
> the table contains real number fields or dates with fractional seconds,[/color]
the[color=blue]
> compare may fail even though nothing has changed. The trick is to avoid[/color]
using[color=blue]
> those data types. Use the Currency (MONEY) type for fractional numbers.
>[color=green]
> >So it's a series of little problems such as this that got us leaning[/color][/color]
towards[color=blue][color=green]
> >an ADP, thinking that would resolve the problem. But the db is pretty[/color][/color]
solid[color=blue][color=green]
> >otherwise. So maybe it's best to leave well enough alone.....[/color]
>
> Keep in in an MDB - you won't be sorry. Keep posting here with the[/color]
problems[color=blue]
> you're running into, and we'll help provide you with the nicest[/color]
workarounds.[color=blue]
>[/color]

re: Access 2003

"Neil Ginsberg" <nrg@nrgconsult.com> wrote:
[color=blue]
>So you would agree with Steve's recommendation to me re. not converting to
>ADP?[/color]

From other's comments yes I'd be inclined to not go to all the extra work involved in
converting an already existing MDB to an ADP. If starting from nothing then I can
see working in ADPs.

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm

re: Access 2003

David W. Fenton wrote:
[color=blue]
> Salad <oil@vinegar.com> wrote in
> news:Yq7uc.15085$Tn6.2747@newsread1.news.pas.earth link.net:
>
>[color=green]
>>I wonder if anyone has told MS that their help files are the worst
>>in the industry or if they sit around and slap each other on that
>>back and share high-5s for their abomination.[/color]
>
>
> The ridiculous thing about it is that the Access 97 help files are
> by far the best help files I've used in any application, bar none.
>
> And the content of the A2K help files is virtually identical.
>
> The problems are entirely in the new UI, not in the actual content.
>[/color]
I have heard the insane do the same thing over and over hoping for
different results. That's how I view the help after A97. Why
perpetrate an atrocity?

BTW, if you REALLY REALLY want to see the best help file system in the
industry download Sybase SQL Server. You'll cry when you compare the
difference between a truely class act and an MS abomination.

re: Access 2003

"Neil Ginsberg" <nrg@nrgconsult.com> wrote in message
news:e2xuc.17595$be.13321@newsread2.news.pas.earth link.net...
[color=blue]
> So you would agree with Steve's recom-
> mendation to me re. not converting to
> ADP?[/color]

I'd have to see some compelling reason to recommend a conversion, and I
haven't seen that, so far.

Just be aware that a well-designed, well-implemented single user application
doesn't automatically make a well-designed, well-implemented multiuser
application and a well-designed, well-implemented multiuser application
doesn't automatically make a well-designed, well-implemented client
application. There are "tricks of the trade" for each, so some "adjustments"
will have to be made for these transitions.

Larry Linson
Microsoft Access MVP

re: Access 2003

Actually, no. It's very wise to only use optimistic locking with a server
database, and doing anything else is difficult and problematic at best, and
impossible with many ODBC back-ends.

On Mon, 31 May 2004 03:00:37 GMT, "Neil Ginsberg" <nrg@nrgconsult.com> wrote:
[color=blue]
>You'd think they'd provide some way to control the type of locking they use.
>Too much trouble I guess.
>
>Anyway, you're saying to avoid using Float data type -- even DateTime type
>(??) -- and use Currency instead?
>
>Neil
>
>
>"Steve Jorgensen" <nospam@nospam.nospam> wrote in message
>news:qutkb01fh8hv02vkvbmkhdptsprfh10eqa@4ax.com.. .[color=green]
>> On Sun, 30 May 2004 23:33:41 GMT, "Neil Ginsberg" <news@nrgconsult.com>[/color]
>wrote:[color=green]
>>[color=darkred]
>> >That's very interesting. I was not aware of the bugs in the ADP file, nor
>> >that there were no net performance gains. I thought the opposite would be
>> >the case, especially since ADO has been around for a while now and has[/color][/color]
>had a[color=green][color=darkred]
>> >chance to mature (but I guess it hasn't?).[/color]
>>
>> It should have had a chance to mature, but Microsoft doesn't seem to be
>> focusing one iota of energy on it, perhaps because hardly anyone ever[/color]
>liked it[color=green]
>> enough to use it.
>>[color=darkred]
>> >The MDB that I set up is for the most part working fine. Where[/color][/color]
>pass-throughs[color=green][color=darkred]
>> >and stored procedures are used, there are no problems (though sometimes[/color][/color]
>it[color=green][color=darkred]
>> >requires a bit of a workaround, since pass-throughs aren't editable).
>> >
>> >The main problems we've been having have been with the bound forms that[/color][/color]
>we[color=green][color=darkred]
>> >use for viewing and editing, which use ODBC linked tables. I set up a
>> >standard view/edit configuration, where the form opens in "view mode"[/color][/color]
>bound[color=green][color=darkred]
>> >to a pass-through query, and then the user clicks Edit and they get an
>> >editable recordset based on a linked table. This has worked OK; but we[/color][/color]
>have[color=green][color=darkred]
>> >a lot of locking issues. Sometimes a table gets locked and can't be[/color][/color]
>updated,[color=green][color=darkred]
>> >even though the only place where another user could be accessing the[/color][/color]
>record[color=green][color=darkred]
>> >is in the list portion of a combo box! So it's been somewhat perplexing[/color][/color]
>and[color=green][color=darkred]
>> >difficult to track down the source of this locking problem (though,
>> >forturnately, it doesn't happen frequently, and not with all tables).[/color]
>>
>> These problems exist in ADPs, too, and the cause/solution is the same.[/color]
>Both[color=green]
>> ADO and DAO use optimistic locking for updating server-side data, and this
>> relies on comparing the pre-edit data to the data currently on the server.[/color]
>If[color=green]
>> the table contains real number fields or dates with fractional seconds,[/color]
>the[color=green]
>> compare may fail even though nothing has changed. The trick is to avoid[/color]
>using[color=green]
>> those data types. Use the Currency (MONEY) type for fractional numbers.
>>[color=darkred]
>> >So it's a series of little problems such as this that got us leaning[/color][/color]
>towards[color=green][color=darkred]
>> >an ADP, thinking that would resolve the problem. But the db is pretty[/color][/color]
>solid[color=green][color=darkred]
>> >otherwise. So maybe it's best to leave well enough alone.....[/color]
>>
>> Keep in in an MDB - you won't be sorry. Keep posting here with the[/color]
>problems[color=green]
>> you're running into, and we'll help provide you with the nicest[/color]
>workarounds.[color=green]
>>[/color]
>[/color]

re: Access 2003

Although Lyle and I agree to disagree, I respect Lyle's technical ability and
knowledge. You should listen to what he says as well as what I say before
making up your mind.

On 31 May 2004 01:23:47 GMT, Lyle Fairfield <MissingAddress@Invalid.Com>
wrote:
[color=blue][color=green]
>> On Sun, 30 May 2004 23:33:41 GMT, "Neil Ginsberg" <news@nrgconsult.com>
>> wrote:
>>[color=darkred]
>>>That's very interesting. I was not aware of the bugs in the ADP file,
>>>nor that there were no net performance gains.[/color][/color]
>
>You might wish to canvass those of us who work regularly with ADPs before you
>write them off. I have delivered several ADP applications over the past ...
>hmmm ... 4? ... years, to a large company in Atlanta, to a proefessional
>organization in Washington, and to several educational institutions. I have
>not found any insurmountable problems with ADPs. My clients are at least as
>happy as they have been previously with MDBs, FoxPro, Foxbase, Clipper and
>DBaseIII.
>It's unlikely that I will be using MDBs for any major application in the
>future. The power of T-SQL and MS-SQL Server, and the superior backup,
>security and protection from corruption of the latter, and the seamless
>interface provided by ADPs create, in my opinion an almost ideal RAD
>platform.[/color]

re: Access 2003

Lyle Fairfield <MissingAddress@Invalid.Com> wrote in
news:Xns94F9D9B39F4B5FFDBA@130.133.1.4:
[color=blue]
> It's unlikely that I will be using MDBs for any major application
> in the future.[/color]

Every time this topic comes up, you do exactly the same thing: you
change the subject.

The original poster asked about *converting* an existing *working*
MDB to an ADP.

That's very different from starting with an ADP from scratch for new
development.

And each time the topic comes up, you follow up in a manner that
confuses the two issues.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

re: Access 2003

On Mon, 31 May 2004 15:29:45 GMT, "David W. Fenton"
<dXXXfenton@bway.net.invalid> wrote:
[color=blue]
>Lyle Fairfield <MissingAddress@Invalid.Com> wrote in
>news:Xns94F9D9B39F4B5FFDBA@130.133.1.4:
>[color=green]
>> It's unlikely that I will be using MDBs for any major application
>> in the future.[/color]
>
>Every time this topic comes up, you do exactly the same thing: you
>change the subject.
>
>The original poster asked about *converting* an existing *working*
>MDB to an ADP.
>
>That's very different from starting with an ADP from scratch for new
>development.
>
>And each time the topic comes up, you follow up in a manner that
>confuses the two issues.[/color]

To be fair, perhaps, I had already confused the 2 issues by saying that I
don't plan to use ADPs again for production code at all and I'm considering
converting one that I did write to an MDB.

re: Access 2003

FWIW, the MDB relies heavily on stored procedures and pass-throughs, though
still does a fair amount with Access queries and DAO code. Moving to an ADP
all the queries and code would need to be converted. I suppose it wouldn't
be worth it, based on what I'm hearing here (i.e., with the ADP the locking
issues and other minor issues wouldn't go away, and might actually get
worse).

Neil

"Larry Linson" <bouncer@localhost.not> wrote in message
news:yAyuc.12284$oh7.9187@nwrddc01.gnilink.net...[color=blue]
> "Neil Ginsberg" <nrg@nrgconsult.com> wrote in message
> news:e2xuc.17595$be.13321@newsread2.news.pas.earth link.net...
>[color=green]
> > So you would agree with Steve's recom-
> > mendation to me re. not converting to
> > ADP?[/color]
>
> I'd have to see some compelling reason to recommend a conversion, and I
> haven't seen that, so far.
>
> Just be aware that a well-designed, well-implemented single user[/color]
application[color=blue]
> doesn't automatically make a well-designed, well-implemented multiuser
> application and a well-designed, well-implemented multiuser application
> doesn't automatically make a well-designed, well-implemented client
> application. There are "tricks of the trade" for each, so some[/color]
"adjustments"[color=blue]
> will have to be made for these transitions.
>
> Larry Linson
> Microsoft Access MVP
>
>[/color]