Slowdown when using A2000 frontend with A97 backend on network

[Bradley]

Has anyone else noticed this problem? I converted the back-end to A2000
and the performance problem was fixed. We supply a 97 and 2000 version
of our software so we kept the backend in A97 to make upgrading simple
for users. We've done it like that for years but a new client has been
having severe performance issues... solved by converting the backend to
2000.
--
regards,

Bradley

[Galina]

Nope. My 2 database applications became noticably faster for users
with front-end converted to Windows 2000. Back-end is still windows
97, because some users are not converted yet.
Galina
"Bradley" <br*****@REMOVE THIScomcen.com. au> wrote in message news:<40******@ nexus.comcen.co m.au>...

Has anyone else noticed this problem? I converted the back-end to A2000
and the performance problem was fixed. We supply a 97 and 2000 version
of our software so we kept the backend in A97 to make upgrading simple
for users. We've done it like that for years but a new client has been
having severe performance issues... solved by converting the backend to
2000.

[Allen Browne]

There is a performance hit working across versions, because A2000 uses JET
4, and the calls must be converted to JET 3.5 to read the data form the A97
back end. The hit is noticable, but not dramatic.

If you have "severe" performance issues, it is more likely associated with
some of the guff in A2000 that needs to be turned off. Name AutoCorrect is
the main culprit. Subdatasheets can't be fixed since they cannot be defined
on the A97 tables. Turning off Row Level locking is also worthwhile - we
found some concurrency issues when A2000 tried to run this and the A97 back
end does not support it.

For general guidance on performance with A2000, see:
http://www.granite.ab.ca/access/performancefaq.htm

--
Allen Browne - Microsoft MVP. Perth, Western Australia.
Tips for Access users - http://allenbrowne.com/tips.html
Reply to group, rather than allenbrowne at mvps dot org.

"Bradley" <br*****@REMOVE THIScomcen.com. au> wrote in message
news:40******@n exus.comcen.com .au...

Has anyone else noticed this problem? I converted the back-end to A2000
and the performance problem was fixed. We supply a 97 and 2000 version
of our software so we kept the backend in A97 to make upgrading simple
for users. We've done it like that for years but a new client has been
having severe performance issues... solved by converting the backend to
2000.

[Bradley]

Allen Browne wrote:

There is a performance hit working across versions, because A2000
uses JET 4, and the calls must be converted to JET 3.5 to read the
data form the A97 back end. The hit is noticable, but not dramatic.

If you have "severe" performance issues, it is more likely associated
with some of the guff in A2000 that needs to be turned off. Name
AutoCorrect is the main culprit. Subdatasheets can't be fixed since
they cannot be defined on the A97 tables. Turning off Row Level
locking is also worthwhile - we found some concurrency issues when
A2000 tried to run this and the A97 back end does not support it.

For general guidance on performance with A2000, see:
http://www.granite.ab.ca/access/performancefaq.htm
Ta. I'm aware of most of the things you listed (learned them the "hard"
way:)

It's solved by converting to A2000 anyway :)
--
regards,

Bradley

"Bradley" <br*****@REMOVE THIScomcen.com. au> wrote in message
news:40******@n exus.comcen.com .au...

Has anyone else noticed this problem? I converted the back-end to
A2000 and the performance problem was fixed. We supply a 97 and 2000
version of our software so we kept the backend in A97 to make
upgrading simple for users. We've done it like that for years but a
new client has been having severe performance issues... solved by
converting the backend to 2000.

--
regards,

Bradley

[Bradley]

Galina wrote:

Nope. My 2 database applications became noticably faster for users
with front-end converted to Windows 2000. Back-end is still windows
97, because some users are not converted yet.
Galina
"Bradley" <br*****@REMOVE THIScomcen.com. au> wrote in message
news:<40******@ nexus.comcen.co m.au>...

Has anyone else noticed this problem? I converted the back-end to
A2000 and the performance problem was fixed. We supply a 97 and 2000
version of our software so we kept the backend in A97 to make
upgrading simple for users. We've done it like that for years but a
new client has been having severe performance issues... solved by
converting the backend to 2000.

We have been running this configuration too for a number of years but a
new client has had major problems (they refuse to use it as it's too
slow). I tested it locally and it was slow for me as well... but yet
other clients are running fine). Converting the back-end to A2000 made a
huge difference.
--
regards,

Bradley

[David W. Fenton]

"Allen Browne" <Al*********@Se eSig.Invalid> wrote in
news:40******** *************** @freenews.iinet .net.au:

Subdatasheets can't be fixed since they cannot be defined
on the A97 tables.

Eh?

I just opened an A2K MDB and linked to A97 data. The linked tables
in the front end automatically had linked subdatasheets where there
were unambiguous relationships defined in the A97 back end. Setting
those linked tables' SUBDATASHEET property to NONE might very well
have a performance benefit, just as it does with pure A2K links.

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

[David W. Fenton]

"Bradley" <br*****@REMOVE THIScomcen.com. au> wrote in
news:40******** @nexus.comcen.c om.au:

It's solved by converting to A2000 anyway :)

I ran a client's application with an A97 back end and A2K front ends
while I did major redevelopment of the app in A97. When we converted
the back end to A2K, we suddenly experienced frequent reports of
corruption (though no real corruption), and had one occurence of the
lost AutoNumber seed.

We eventually got everything running right by making sure all the
workstations had SR1a or higher and Jet 4.0 SP6 (which was the
latest back then). This meant visiting and updating every
workstation, including Win2K service packs on all the workstations
still running the original release of Win2K (about half of them --
Jet SP6 will only install on Win2K SP1 and higher).

The performance improvement was quite minimal.

Worth it in the long run?

I don't know.

But the lack of corruption might be worth something to somebody.

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

[Bradley]

David W. Fenton wrote:

"Bradley" <br*****@REMOVE THIScomcen.com. au> wrote in
news:40******** @nexus.comcen.c om.au:

It's solved by converting to A2000 anyway :)

I ran a client's application with an A97 back end and A2K front ends
while I did major redevelopment of the app in A97. When we converted
the back end to A2K, we suddenly experienced frequent reports of
corruption (though no real corruption), and had one occurence of the
lost AutoNumber seed.

We eventually got everything running right by making sure all the
workstations had SR1a or higher and Jet 4.0 SP6 (which was the
latest back then). This meant visiting and updating every
workstation, including Win2K service packs on all the workstations
still running the original release of Win2K (about half of them --
Jet SP6 will only install on Win2K SP1 and higher).

The performance improvement was quite minimal.

Worth it in the long run?

I don't know.

But the lack of corruption might be worth something to somebody.

Yeah...

The difference for me was dramatic.. probably caused by a number of
factors.
--
regards,

Bradley

[Allen Browne]

By "fixed", I intended "turned off".

Last time I visted that issue, David, I could not get the SubDatasheetNam e
setting to hold "[None]" in a linked table attached to an A97 b.e. I assumed
that was because the b.e. did not support the property, so the linked table
in the f.e. did not hold the property.

The result is that you DO get the performance loss and Datasheet issues
related to the presence of subdatasheets in these linked tables.

--
Allen Browne - Microsoft MVP. Perth, Western Australia.
Tips for Access users - http://allenbrowne.com/tips.html
Reply to group, rather than allenbrowne at mvps dot org.

"David W. Fenton" <dX********@bwa y.net.invalid> wrote in message
news:Xn******** *************** ***********@24. 168.128.86...

"Allen Browne" <Al*********@Se eSig.Invalid> wrote in
news:40******** *************** @freenews.iinet .net.au:

Subdatasheets can't be fixed since they cannot be defined
on the A97 tables.

Eh?

I just opened an A2K MDB and linked to A97 data. The linked tables
in the front end automatically had linked subdatasheets where there
were unambiguous relationships defined in the A97 back end. Setting
those linked tables' SUBDATASHEET property to NONE might very well
have a performance benefit, just as it does with pure A2K links.

[Dimitri Furman]

On Apr 23 2004, 07:27 am, "Allen Browne" <Al*********@Se eSig.Invalid>
wrote in news:40******** *************** @freenews.iinet .net.au:

By "fixed", I intended "turned off".

Last time I visted that issue, David, I could not get the
SubDatasheetNam e setting to hold "[None]" in a linked table attached
to an A97 b.e. I assumed that was because the b.e. did not support the
property, so the linked table in the f.e. did not hold the property.

That is correct, however you can add that property as a custom property to
the backend tabledef in A97 and set it to "[None]". Works just fine.

--
remove a 9 to reply by email