David W. Fenton wrote:
I'm setting up a project for a client on a new Windows Terminal
Server. The application is currently in A2K, but the sysadmin does
not want to install that, he wants to install A2K3, because Office
2K3 is the organization's new standard (they want to be fully
converted within the new calendar year).
What issues will I have, if any, with A2K3 on WTS? Anything
different from A2K? Anything not specific to WTS that I need to know
about A2K3, which I've never used, ever?
--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc
David,
I've had great success with that particular setup. I develop in A2K,
but one client in particular has been running an A2K FE/A2K BE using
A2K3 on WTS and haven't come across any major problems in over 2 years.
Well, except that I keep forgetting the workgroup administrator is
accessed via Tools|Security and not from a separate program. I like
the fact that A2K3 opens an A2K db and allows new queries, reports,
etc. without having to convert the db.
I have had to make table changes over time via VBA (adding tables with
appropriate security, adding fields, modifying fields) and haven't run
into any issues there once it passed testing on my A2K development
machine. All coding currently in my application has worked fine. BTW,
I still use DAO rather than ADO.
There is still the rare crash/corruption, but that has dropped
dramatically since I convinced them to put the BE on the TServer as
well as the FE. (That was due to intermittent network hiccups that
they never fully resolved, but they only seemed to affect Access
databases.) And when A2K3 does a repair, it makes a copy prior to
running the repair. A nice feature, but I had already learned the hard
way to always make a backup first. (Thanks, Peter Miller.)
I haven't found a case for A2K3 over A2K in my situation, but at least
they work and play very well together.