New Access Version?

[Neil Ginsberg]

Does anyone know if a new version of Access is due to come out anytime soon?

Thanks,

Neil

[David W. Fenton]

"H" <[e-mail]> wrote in
news:cs**********@hercules.btinternet.com:

"David W. Fenton" <dX********@bway.net.invalid> wrote in message
news:Xn**********************************@24.168.1 28.78...

"H" <[e-mail]> wrote in
news:cs**********@sparta.btinternet.com:

It's safe to say that Microsoft want to drop
support for jet and make MSDE the default database engine (we
know it can be installed silently and without user input).
That would be lunacy of the highest sort for them to do so.

It would mean the dropping of the MDB format, since IT'S A
FRIGGING JET DB.

The format would be ADP

That would mean I'd stop developing in Access, as ADPs are a
complete mess and unusable by anyone who wants to be productive,
rather than constantly working around the inadequacies of this
half-baked format that was itself created for a stupid reason (to
get a Jet-less connection to SQL Server).

In any event, yes, you're just repeating what I said.

But think about what that would mean: it would mean the complete
abandonment of Access's entire legacy (an MDB can't be converted to
an ADP), and it would replace a full-featured, easy-to-use format
with one that is lacking in features and hard to understand and use.

It ain't gonna happen.

Furthermore, Jet is not dead at all -- it's running
ActiveDirectory's data store, for instance (this is why from
Win2K on the Jet 4 DLLs are protected OS files).

I understood that SQL Server was used in Server 2003.

That I didn't know. Do you have a citation for that? I was unable to
Google anything about it.

Jet will never be dropped unless Access completely drops all
legacy support. It may be dropped as the default DB engine, but
that would be stupid as well, since it would mean double workset
(i.e., to open an MDB you have to have Jet loaded).

The default format will be an ADP.

That can't happen until ADPs are vastly improved in functionality,
reliability and usability.
Jet will (one day) disappear.
In my opinion, only when Access itself disappears.
Jet's a big headach to MS.
Yes, because it's simply way too good at the tasks it performs and
makes it impossible for MS to force people to spend billions on
licenses for SQL Server.
Let's hope that MS have a momentary lapse of reason and give us
Jet.Net (Here's hoping).

I don't think Jet will ever be enhanced.

I also don't think it will ever be dropped, except when Access
itself is no longer an actively developed product (or has morphed
into something wholly unrelated to its current incarnation).

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

[David W. Fenton]

Stephen K. Young" <s k y @ stanleyassociates . com> wrote in
news:35*************@individual.net:

I noticed this interesting Microsoft quote that indicates DAO will
NOT be available in 64-bit Windows (targeted for 2006?):

"Data Access Objects (DAO): DAO provides access to JET (Access)
databases. This API can be used from Microsoft Visual Basic®,
Microsoft Visual C++®, and scripting languages. It was included
with Microsoft Office 2000 and Office XP. DAO 3.6 is the final
version of this technology. It will not be available on the 64-bit
Windows operating system."

That's interesting, but probably inevitable, as it's not
thread-safe, according to MichKa, whereas ADO to Jet *is*
thread-safe.

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

[David W. Fenton]

Steve Jorgensen <no****@nospam.nospam> wrote in
news:0d********************************@4ax.com:

Sorry - that's right. It happens if you edit the code in A2K3. I
have not seen that compiling in A2K2 before saving helps since I
always do that.

Well, there's compiling and then there's successful compiling. In my
experience, A2K and beyond are much more susceptible to failed 100%
compile without complaining about it.

And, of course, I always work with conditional compilation turned
off.

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

[Neil Ginsberg]

Jet's a big headach to MS.

Yes, because it's simply way too good at the tasks it performs and
makes it impossible for MS to force people to spend billions on
licenses for SQL Server.

Good one! :-)

Reminds me of when Fox Pro was vastly superior to any MS product and so MS
bought it so that they could effectively shelve it.

Neil

[Neil Ginsberg]

"David W. Fenton" <dX********@bway.net.invalid> wrote in message
news:Xn**********************************@24.168.1 28.78...

Steve Jorgensen <no****@nospam.nospam> wrote in
news:0d********************************@4ax.com:

Sorry - that's right. It happens if you edit the code in A2K3. I
have not seen that compiling in A2K2 before saving helps since I
always do that.
Well, there's compiling and then there's successful compiling. In my
experience, A2K and beyond are much more susceptible to failed 100%
compile without complaining about it.

And, of course, I always work with conditional compilation turned
off.

"Conditional compilation"? You mean "background compilation"?

Neil

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

[rkc]

Steve Jorgensen wrote:

For instance, if I can make a single procedure that can extract a collection
of values from any named attribute of each object in a collection, I would do
that using a call to CallByName on each object to get the value.

That might be useful with small collections. The late binding issue
could translate into performance issues with large collections.
Maybe a Visitor pattern?

[Steve Jorgensen]

On Thu, 20 Jan 2005 02:58:36 GMT, rkc <rk*@rochester.yabba.dabba.do.rr.bomb>
wrote:

Steve Jorgensen wrote:

For instance, if I can make a single procedure that can extract a collection
of values from any named attribute of each object in a collection, I would do
that using a call to CallByName on each object to get the value.

That might be useful with small collections. The late binding issue
could translate into performance issues with large collections.
Maybe a Visitor pattern?

You're right, but I find it's not much of an issue. For one thing, the vast
majority of collections in my applications are small (partly because I use a
collections for a lot of things). Also, the vtable lookups turn out to not be
as slow as one might guess, so even collections with up to a couple thousand
elements qualify as small for most performance concerns.

[Tom van Stiphout]

On Wed, 19 Jan 2005 05:17:59 GMT, "Neil Ginsberg" <nr*@nrgconsult.com>
wrote:

Yes. In A2000 you often get warnings that the implementation is not
complete. E.g. when editing a table design that has field
descriptions.
The Create View window is also better.
The column widths of table views and query views can be saved.

These are the first that come to mind, but there are more differences.

-Tom.

SQL Server support is different than in A2000?

"Tom van Stiphout" <no*************@cox.net> wrote in message
news:kv********************************@4ax.com.. .

On Tue, 18 Jan 2005 21:16:14 GMT, Tony Toews <tt****@telusplanet.net>
wrote:

Today we had a corruption in an A2003 database after Copy/Pasting a
form object. It's still not perfect, but I too like A2003 quite a bit
better than A2000, especially the SQL Server support.
-Tom.
<clip>

Agreed. I found that doing work in A2000 a form would corrupt about once
a week or
so. A2003 hasn't had this problem at all.

<clip>

[H]

I base these statements on the obvious trend to move as much as possible to
run from with in the .NET framework.

We know that SQL Server will shortly become object orientated, how long will
it be before VBA and Jet are moved in that direction.

I hope it does because of the obvious advantages that would bring.

Jet's a headach, because it's become so popular and will not be an easy
thing to move forwards.

These are my thoughts.

Regards

H
"Tony Toews" <tt****@telusplanet.net> wrote in message
news:gj********************************@4ax.com...

"H" <[e-mail]> wrote:

It would mean the dropping of the MDB format, since IT'S A FRIGGING
JET DB.

The format would be ADP

Furthermore, Jet is not dead at all -- it's running
ActiveDirectory's data store, for instance (this is why from Win2K
on the Jet 4 DLLs are protected OS files).

I understood that SQL Server was used in Server 2003.

Jet will never be dropped unless Access completely drops all legacy
support. It may be dropped as the default DB engine, but that would
be stupid as well, since it would mean double workset (i.e., to open
an MDB you have to have Jet loaded).

The default format will be an ADP.

Jet will (one day) disappear.

Jet's a big headach to MS.

Let's hope that MS have a momentary lapse of reason and give us Jet.Net
(Here's hoping).

On what do you base these statements? How is Jet a big headache?

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

[H]

Sorry, Had not realised that an ADP file had so much problems
H

"David W. Fenton" <dX********@bway.net.invalid> wrote in message
news:Xn**********************************@24.168.1 28.78...

"H" <[e-mail]> wrote in
news:cs**********@hercules.btinternet.com:

"David W. Fenton" <dX********@bway.net.invalid> wrote in message
news:Xn**********************************@24.168.1 28.78...

"H" <[e-mail]> wrote in
news:cs**********@sparta.btinternet.com:

It's safe to say that Microsoft want to drop
support for jet and make MSDE the default database engine (we
know it can be installed silently and without user input).

That would be lunacy of the highest sort for them to do so.

It would mean the dropping of the MDB format, since IT'S A
FRIGGING JET DB.
The format would be ADP

That would mean I'd stop developing in Access, as ADPs are a
complete mess and unusable by anyone who wants to be productive,
rather than constantly working around the inadequacies of this
half-baked format that was itself created for a stupid reason (to
get a Jet-less connection to SQL Server).

In any event, yes, you're just repeating what I said.

But think about what that would mean: it would mean the complete
abandonment of Access's entire legacy (an MDB can't be converted to
an ADP), and it would replace a full-featured, easy-to-use format
with one that is lacking in features and hard to understand and use.

It ain't gonna happen.

Furthermore, Jet is not dead at all -- it's running
ActiveDirectory's data store, for instance (this is why from
Win2K on the Jet 4 DLLs are protected OS files).

I understood that SQL Server was used in Server 2003.

That I didn't know. Do you have a citation for that? I was unable to
Google anything about it.

It was in a book for Windows 2003 Server. I do not have the book with me at
present to reference.

Jet will never be dropped unless Access completely drops all
legacy support. It may be dropped as the default DB engine, but
that would be stupid as well, since it would mean double workset
(i.e., to open an MDB you have to have Jet loaded).

The default format will be an ADP.

That can't happen until ADPs are vastly improved in functionality,
reliability and usability.

Jet will (one day) disappear.

In my opinion, only when Access itself disappears.

Jet's a big headach to MS.

Yes, because it's simply way too good at the tasks it performs and
makes it impossible for MS to force people to spend billions on
licenses for SQL Server.

Let's hope that MS have a momentary lapse of reason and give us
Jet.Net (Here's hoping).

I don't think Jet will ever be enhanced.

I also don't think it will ever be dropped, except when Access
itself is no longer an actively developed product (or has morphed
into something wholly unrelated to its current incarnation).

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

[J. Clay]

Everyone seems to come down hard on ADPs. I converted our system to ADP/SQL
three years ago and my experience has been quite possitive. I think the
biggest issue is that you need to change your paradigm and think in a single
record mentality on forms. The system I originally developed in A97 and are
up to A2002 and it has continually grown in functionality and complexity.
It has will over 100 tables, 100 Stored procedures and probably that many
views.

The biggest change I made is that I DO NOT use the built in navigation. I
know at first thought this doesn't seem right, since that is one of the
benefits of working in Access. Instead, I use a stored procedure as the
record source for ALL of my main forms and use input parameters. This way,
only 1 record is returned by the server no matter what. This works very
well in house and has the benefit of 1) disabling the mouse wheel and 2)
give relatively good and usable performance over a WAN.

Anyway, I personally like the ADP format and hope that it is at least
maintained and enhanced.

Just my $.10 -- inflation you know :)
Jim
"David W. Fenton" <dX********@bway.net.invalid> wrote in message
news:Xn**********************************@24.168.1 28.78...

"H" <[e-mail]> wrote in
news:cs**********@hercules.btinternet.com:

"David W. Fenton" <dX********@bway.net.invalid> wrote in message
news:Xn**********************************@24.168.1 28.78...

"H" <[e-mail]> wrote in
news:cs**********@sparta.btinternet.com:

It's safe to say that Microsoft want to drop
support for jet and make MSDE the default database engine (we
know it can be installed silently and without user input).

That would be lunacy of the highest sort for them to do so.

It would mean the dropping of the MDB format, since IT'S A
FRIGGING JET DB.

The format would be ADP

That would mean I'd stop developing in Access, as ADPs are a
complete mess and unusable by anyone who wants to be productive,
rather than constantly working around the inadequacies of this
half-baked format that was itself created for a stupid reason (to
get a Jet-less connection to SQL Server).

In any event, yes, you're just repeating what I said.

But think about what that would mean: it would mean the complete
abandonment of Access's entire legacy (an MDB can't be converted to
an ADP), and it would replace a full-featured, easy-to-use format
with one that is lacking in features and hard to understand and use.

It ain't gonna happen.

Furthermore, Jet is not dead at all -- it's running
ActiveDirectory's data store, for instance (this is why from
Win2K on the Jet 4 DLLs are protected OS files).

I understood that SQL Server was used in Server 2003.

That I didn't know. Do you have a citation for that? I was unable to
Google anything about it.

Jet will never be dropped unless Access completely drops all
legacy support. It may be dropped as the default DB engine, but
that would be stupid as well, since it would mean double workset
(i.e., to open an MDB you have to have Jet loaded).

The default format will be an ADP.

That can't happen until ADPs are vastly improved in functionality,
reliability and usability.

Jet will (one day) disappear.

In my opinion, only when Access itself disappears.

Jet's a big headach to MS.

Yes, because it's simply way too good at the tasks it performs and
makes it impossible for MS to force people to spend billions on
licenses for SQL Server.

Let's hope that MS have a momentary lapse of reason and give us
Jet.Net (Here's hoping).

I don't think Jet will ever be enhanced.

I also don't think it will ever be dropped, except when Access
itself is no longer an actively developed product (or has morphed
into something wholly unrelated to its current incarnation).

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

[Tony Toews]

"H" <[e-mail]> wrote:

I base these statements on the obvious trend to move as much as possible to
run from with in the .NET framework.
Not obvious to me. If an app works fine in Access why should it be moved to .Net.
It's still not as productive an environment as Access. Now if you had 5,000 users
on the Internet accessing the app then I can see why a .Net app would be better.
We know that SQL Server will shortly become object orientated, how long will
it be before VBA and Jet are moved in that direction.

I hope it does because of the obvious advantages that would bring.
What obvious advantages does object orientation bring? How do we know that SQL
Server will become OO?
Jet's a headach, because it's become so popular and will not be an easy
thing to move forwards.

<shrug> Then MS should make the migration to SQL Server easier.

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

[Tony Toews]

"David W. Fenton" <dX********@bway.net.invalid> wrote:

Make MSDE the default database engine? That's fine by me so long
as it's about as easy to use as Jet.

There are terrible problems with conflicts between multiple
applications installing the MSDE, since a lot of commercial
applications use MSDE as their data store. I've run into with
conflicts between Veritas Backup and Blackberry Server.

It's a new form of DLL hell, and something that I really don't think
any of us need.

What about the Named Instances? I thought each such had it's own set of DLLs and
SPs? But I don't know much about those as I've never used them in production.

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

[David W. Fenton]

Tony Toews <tt****@telusplanet.net> wrote in
news:nv********************************@4ax.com:

"David W. Fenton" <dX********@bway.net.invalid> wrote:

Make MSDE the default database engine? That's fine by me so
long as it's about as easy to use as Jet.

There are terrible problems with conflicts between multiple
applications installing the MSDE, since a lot of commercial
applications use MSDE as their data store. I've run into with
conflicts between Veritas Backup and Blackberry Server.

It's a new form of DLL hell, and something that I really don't
think any of us need.

What about the Named Instances? I thought each such had it's own
set of DLLs and SPs? But I don't know much about those as I've
never used them in production.

It has more to do with installers being stupid than with
capabilities of MSDE itself.

That is, just like DLL hell.

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

[Steve]

Why a backup program requires you to install MSDE is baffling. Our
consultants installed the program on our file server, and I realized
that now I have another service running on the box. Even if I had a
seperate SQL Server box, I would still need this running. A simple
link-list file would have been fine to keep tract of the file backup.

Steven

On Fri, 21 Jan 2005 00:01:01 GMT, "David W. Fenton"
<dX********@bway.net.invalid> wrote:

Tony Toews <tt****@telusplanet.net> wrote in
news:nv********************************@4ax.com :

"David W. Fenton" <dX********@bway.net.invalid> wrote:

Make MSDE the default database engine? That's fine by me so
long as it's about as easy to use as Jet.

There are terrible problems with conflicts between multiple
applications installing the MSDE, since a lot of commercial
applications use MSDE as their data store. I've run into with
conflicts between Veritas Backup and Blackberry Server.

It's a new form of DLL hell, and something that I really don't
think any of us need.

What about the Named Instances? I thought each such had it's own
set of DLLs and SPs? But I don't know much about those as I've
never used them in production.

It has more to do with installers being stupid than with
capabilities of MSDE itself.

That is, just like DLL hell.

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

[David W. Fenton]

st***@nospam.com (Steve) wrote in
news:42**************@news.westnet.com:

Why a backup program requires you to install MSDE is baffling. . .
It's not to me -- it uses the MSDE to store its catalogs.
. . . Our
consultants installed the program on our file server, and I
realized that now I have another service running on the box. Even
if I had a seperate SQL Server box, I would still need this
running. A simple link-list file would have been fine to keep
tract of the file backup.

I see no real problem with the concept of a backup program actually
using a database to store its data.

It's Microsoft's implementation of the MSDE installers that is the
problem.

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

[Steve]

On Sun, 06 Feb 2005 00:18:46 GMT, "David W. Fenton"
<dX********@bway.net.invalid> wrote:

st***@nospam.com (Steve) wrote in
news:42**************@news.westnet.com:

Why a backup program requires you to install MSDE is baffling. . .
It's not to me -- it uses the MSDE to store its catalogs.

I know, it was the backup program that requires it.

. . . Our
consultants installed the program on our file server, and I
realized that now I have another service running on the box. Even
if I had a seperate SQL Server box, I would still need this
running. A simple link-list file would have been fine to keep
tract of the file backup.
I see no real problem with the concept of a backup program actually
using a database to store its data.

I like keeping things simple and stupid. I just don't see the data
requirements of a backup program that requires the functionallity MSDE
(SQL Server lite). There is no real concurrency issues, nor the need
for triggers or stored procedures. It is not a client server system.
Some of us don't want to run SQL Sever on our file server.

Now maybe the backup program can be installed on a work station, but
our outside consultants dumped it on the file server.

It's Microsoft's implementation of the MSDE installers that is the
problem.

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

[David W. Fenton]

st***@nospam.com (Steve) wrote in
news:42***************@news.westnet.com:

On Sun, 06 Feb 2005 00:18:46 GMT, "David W. Fenton"
<dX********@bway.net.invalid> wrote:

I see no real problem with the concept of a backup program
actually using a database to store its data.

I like keeping things simple and stupid. I just don't see the
data requirements of a backup program that requires the
functionallity MSDE (SQL Server lite). There is no real
concurrency issues, nor the need for triggers or stored
procedures. It is not a client server system. Some of us don't
want to run SQL Sever on our file server.

What database engine would you suggest? Seagate used to use Jet,
with predictable conflicts with Access when installed on the same
machine (not likely on a server, but I had the Seagate software
installed on my workstation to run my backup tape).

When the requirements for the db engine are:

1. runs on all versions of Windows.

2. can be licensed for 3rd-party distribution.

3. is supported by a reliable company.

your choices are pretty limited.

The Veritas catalogs are *very* complex, as is necessitated by
backing up NTFS volumes, where you have to store all sorts of
information about the files, not just the filename, date and path.

Second, the structure of the catalogs is by definition relational,
so you *do* need a relational database.

So, given those aspects, I don't see how Veritas could choose
anything *other* than MSDE.

The only question for me is why, if MS wants MSDE to be the answer
for every company asking the 3 questions above, Microsoft doesn't do
a better job of making MSDE install so that it doesn't step on other
runtime installations.
Now maybe the backup program can be installed on a work station,
but our outside consultants dumped it on the file server.

Backup programs belong on a server if they are backing up servers.

Maybe you don't know too much about backup programs?

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

[Steve Jorgensen]

On Sun, 06 Feb 2005 23:44:11 GMT, "David W. Fenton"
<dX********@bway.net.invalid> wrote:

st***@nospam.com (Steve) wrote in
news:42***************@news.westnet.com:

On Sun, 06 Feb 2005 00:18:46 GMT, "David W. Fenton"
<dX********@bway.net.invalid> wrote:

I see no real problem with the concept of a backup program
actually using a database to store its data.

I like keeping things simple and stupid. I just don't see the
data requirements of a backup program that requires the
functionallity MSDE (SQL Server lite). There is no real
concurrency issues, nor the need for triggers or stored
procedures. It is not a client server system. Some of us don't
want to run SQL Sever on our file server.

What database engine would you suggest? Seagate used to use Jet,
with predictable conflicts with Access when installed on the same
machine (not likely on a server, but I had the Seagate software
installed on my workstation to run my backup tape).

When the requirements for the db engine are:

1. runs on all versions of Windows.

2. can be licensed for 3rd-party distribution.

3. is supported by a reliable company.

your choices are pretty limited.

The Veritas catalogs are *very* complex, as is necessitated by
backing up NTFS volumes, where you have to store all sorts of
information about the files, not just the filename, date and path.

Second, the structure of the catalogs is by definition relational,
so you *do* need a relational database.

So, given those aspects, I don't see how Veritas could choose
anything *other* than MSDE.

The only question for me is why, if MS wants MSDE to be the answer
for every company asking the 3 questions above, Microsoft doesn't do
a better job of making MSDE install so that it doesn't step on other
runtime installations.

Now maybe the backup program can be installed on a work station,
but our outside consultants dumped it on the file server.

Backup programs belong on a server if they are backing up servers.

Maybe you don't know too much about backup programs?

Well - jumping in here - to my mind, a stand-alone database server service is
overkill for an application that has all components running on one machine.
It also has many more installation issues than an in-process database engine
like JET with DAO or ADO.

With JET, there is the versioning issue, but there have been very fiew JET
backward compatability problems that I've seen (except sp7). With MSDE,
there's literally another server process that must be corectly installed, and
must be started and stopped at the appropriate times, etc.

I just can't see why MDSE is preferable to JET here. Even when complex data
integrity rules apply, there's only one application using the data store, so
the enforcement can simply be in a data access code layer, and need not be
implemented as triggers, etc. In fact, IMO, triggers are much harder to write
and maintain than data access layers.

[Steve]

On Sun, 06 Feb 2005 23:44:11 GMT, "David W. Fenton"
<dX********@bway.net.invalid> wrote:

st***@nospam.com (Steve) wrote in
news:42***************@news.westnet.com:

Now maybe the backup program can be installed on a work station,
but our outside consultants dumped it on the file server.

Backup programs belong on a server if they are backing up servers.

Maybe you don't know too much about backup programs?

--

Veritas is able to backup servers which it is not located on. Maybe
you are using an older version?

The rest of your post, though, was informative.

Steven

[David W. Fenton]

st***@nospam.com (Steve) wrote in
news:42***************@news.westnet.com:

On Sun, 06 Feb 2005 23:44:11 GMT, "David W. Fenton"
<dX********@bway.net.invalid> wrote:

st***@nospam.com (Steve) wrote in
news:42***************@news.westnet.com:

Now maybe the backup program can be installed on a work station,
but our outside consultants dumped it on the file server.

Backup programs belong on a server if they are backing up servers.

Maybe you don't know too much about backup programs?

Veritas is able to backup servers which it is not located on.
Maybe you are using an older version?

As is every modern enterprise-level backup program.

Backup programs don't belong on workstations, unless the workstation
is being backed up. And if more than one machine is being backed up,
the backup software belongs on a server.

The only Veritas backup software I've any recent experience with is
the enterprise-level version, which, by definition, is designed to
be running on a server. When I took over the client who was using
it, there were two servers, and when we retired one of those and
replaced it with a new Win2K3 Server box, we repurposed the old box
as a backup server and Blackberry server (it was also doing a number
of other minor tasks). This left the Exchange server and file server
unencumbered by issues associated with running other software.

And Blackberry server uses MSDE, too.

Hence, my experience with the conflict.

However, it was basically more of a conflict between the two
installers than it was an actual conflict between *using* MSDE. We
eventually found that installing the Veritas software, then
installing the Blackberry server software and manually upgrading
MSDE took care of the problems.

But the problem shouldn't exist in the first place (of course,
Blackberry server doesn't need to use MSDE -- it can use any SQL
Server you've got available, if you grant it the appropriate
permissions to do so), and it's Microsoft's fault that it does.

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