delete a record

[Pammy]

I am trying to delete one record in a large table that I have, but I keep
getting an ODBC error and it will not let me delete it. Any idea?

 

[Arvin Meyer [MVP]]

I am trying to delete one record in a large table that I have, but I keep
getting an ODBC error and it will not let me delete it. Any idea?

We'll need more information than that. What is the database engine that you
are connected to with ODBC? On what server is it running? What permissions
do you have on that server? What is the error number and message?

 

[Tom van Stiphout]

On Tue, 25 Mar 2008 06:00:01 -0700, Pammy

My crystal ball is in repairs right now so I can't see what error you
were getting. Can you reply and let us know?

ODBC seems to indicate you are connecting to a non-MsAccess data
source. Which one? Perhaps you can delete the record with tools from
that database system?

-Tom.

 

[Jeff Boyce]

Pammy

As Tom and Arvin have indicated, more info, please!

(also, do you have Delete permissions on the underlying data source?)

Regards

Jeff Boyce
Microsoft Office/Access MVP

 

[aaron.kempf]

If you used SQL Server directly-- you wouldn't have to deal with 12
different layers of complexity.

With MDB you literally have 12 layers between you and the database.

With SQL Server / ADO-- you have _ONE_ layer.

You might have a trigger on the source system-- that won't allow
certain deletes (records more than X number of days old).
In a real database- you can enforce this on the database side.

With SQL Server-- you have this thing called 'tools' where if you have
a SQL Statement; you can take it directly to the DB server and test
it.

Access MDB doesn't have _ANY_ tools because it hasnt' been fixed in a
decade.

Thanks & Good Luck-

-Aaron

 

[Stefan Hoffmann]

With SQL Server / ADO-- you have _ONE_ layer.

Huh? When did all the OSI layers disappear into thin air?

You have only one additional layer using VC and sql.h on a local SQL
Server. As ADO uses these interfaces at a higher level using ADO makes
it a total of at least two - see 2 - layers.

q.e.d.

mfG
--> stefan <--

 

[aaron_kempf]

wow.. thanks

I just love how Microsofts 'you should use MDB to link to SQL Server
because it has less layers'.

The most blatantly wrong thing I've ever heard in my life.

-Aaron

 

[George Hepworth]

Could you cite the source for that MS quote you posted? I'd like to read
more about it directly from the MS source where you read it.

Thanks.



wow.. thanks

I just love how Microsofts 'you should use MDB to link to SQL Server
because it has less layers'.

The most blatantly wrong thing I've ever heard in my life.

 

[Tony Toews [MVP]]

If you used SQL Server directly-- you wouldn't have to deal with 12
different layers of complexity.

With MDB you literally have 12 layers between you and the database.

With SQL Server / ADO-- you have _ONE_ layer.

Prove it.

Access MDB doesn't have _ANY_ tools because it hasnt' been fixed in a
decade.

Rubbish.

Mind you ADPs haven't been enhanced for, what, at least five years now
if not longer.

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's Microsoft Access Blog - http://msmvps.com/blogs/access/

 

[aaron.kempf]

I disagree Tony.

Not only-- do I disagree-- you are WRONG and you are _LYING_.

ADPs have hundreds of improvements in Access 2007.

I will not put up with your mis-information.
And please note-- that MDB didn't get a single update from
2000-2007..

DAO wasn't even included in 2 versions of Office.. and now all of a
sudden 'you were right all along'?

I call hogwash, dog.

DAO sucks a big fat _CO%K_.

MDB didn't have any improvements for a decade. What's your point? ADP
has hundreds of improvements in this version.
MDB didn't have any improvements for a decade. What's your point? ADP
has hundreds of improvements in this version.
MDB didn't have any improvements for a decade. What's your point? ADP
has hundreds of improvements in this version.
MDB didn't have any improvements for a decade. What's your point? ADP
has hundreds of improvements in this version.
MDB didn't have any improvements for a decade. What's your point? ADP
has hundreds of improvements in this version.
MDB didn't have any improvements for a decade. What's your point? ADP
has hundreds of improvements in this version.
MDB didn't have any improvements for a decade. What's your point? ADP
has hundreds of improvements in this version.
MDB didn't have any improvements for a decade. What's your point? ADP
has hundreds of improvements in this version.
MDB didn't have any improvements for a decade. What's your point? ADP
has hundreds of improvements in this version.
MDB didn't have any improvements for a decade. What's your point? ADP
has hundreds of improvements in this version.
MDB didn't have any improvements for a decade. What's your point? ADP
has hundreds of improvements in this version.
MDB didn't have any improvements for a decade. What's your point? ADP
has hundreds of improvements in this version.
MDB didn't have any improvements for a decade. What's your point? ADP
has hundreds of improvements in this version.
MDB didn't have any improvements for a decade. What's your point? ADP
has hundreds of improvements in this version.
MDB didn't have any improvements for a decade. What's your point? ADP
has hundreds of improvements in this version.
MDB didn't have any improvements for a decade. What's your point? ADP
has hundreds of improvements in this version.
MDB didn't have any improvements for a decade. What's your point? ADP
has hundreds of improvements in this version.

-Aaron

 

[aaron.kempf]

Tony;

here is my proof

--------------------------
I am trying to delete one record in a large table that I have, but I
keep
getting an ODBC error and it will not let me delete it. Any idea?
--------------------------


THANKS@!


-Aaron aka the only one out here that _EARNED_ their cert.

 

[aaron.kempf]

I'll try to find it soon.. I might need to use www.archive.org in
order to find it-- because they constantly change content.

Thanks

-Aaron

 

[aaron.kempf]

I am looking at finding the original verbage here:
http://blogs.msdn.com/access/archive/2006/07/27/new-more-complete-access-overview.aspx

I know that it said it specifically didn't reccomend moving away from
ADP reports because of the vastly superior performance.

Here are some additonal quotes quotes
#1
ADP's and Access 12 Security:

The ADP architecture is conceptually unchanged between Access 2003 and
Access12, which means that the features continue to work in
essentially the same way they did. We continue to believe that SQL
Server makes a great store for Access data and that building the UI
either through linked tables or ADPs will continue to work well.

#2
Also-- here is a great artice for more information about ADP
http://office.microsoft.com/en-us/access/HA101679531033.aspx

#3
ADP are not gone
http://blogs.msdn.com/thirdoffive/archive/2006/06/01/611032.aspx

#4
ADP are _MUCH_ faster than MDB, especially for Reporting - again I
can't find this link, but i will

#5
HotFixes for ADP performance ( to dispell everythign all the MVPs say)
http://blogs.msdn.com/clintcovington/archive/2007/05/21/hot-fixes-for-three-access-2007-issues.aspx

#6
Access brings too many records records to the client
http://blogs.msdn.com/sqlexpress/pages/616581.aspx
The Jet query processor will send all queries to the server that can
be processed by the server (from aaron- this is technically mis-
worded-- things _CAN_ be processed by the server; I'll be glad to
demonstrate). If queries contain elements (such as VBA expressions or
heterogeneous joins) that cannot be processed on the server, then all
or part of the query will be processed on the client.

#7
http://blogs.msdn.com/access/archive/2006/04/25/better-looking-forms-reports-faster.aspx
# ADD said on May 1, 2006 10:37 AM:
Will we be able to create and edit tables and views in SQL Server 2005
as we were with Access 2003 and SQL Server 2000? # Clint said on May
2, 2006 1:24 PM:
Yes. Beta 2 will support editing tables and views in SQL Server 2005
in ADPs. # ADD said on May 3, 2006 10:04 AM:
Oh my Clint. You made my week! We've been strugling with Management
Studio since we switched to SQL Server 2005. This has renewed my
faith in Microsoft. Thank you!

#8
Why would Microsoft print a book on this if they weren't commited to
this?
http://www.amazon.com/Microsoft-Acc...=sr_1_1?ie=UTF8&s=books&qid=1206482385&sr=8-1

#9
http://www.amazon.com/gp/reader/0735610029
Page 4-
SQL Server 2000 And Access 2002 feature a large number of
improvements, particularly for tasks that require programming with
Access Projects

#10
http://www.amazon.com/gp/reader/0735619425
Page 535-
The introduction of Access Projects with Access 2000 did not eliminate
(this) linked table capability, but it's functionality is dwarfed by
the vastly superrio capabilites of Acces projcts

#11
http://www.amazon.com/gp/reader/0735619425
Page 535-
By using server-side filters, you can improve the performance of your
forms because less data will move over a network

#12
http://www.amazon.com/gp/reader/0735619425
Page 535-







-Aaron

 

[George]

I am not excited about wading through all those links looking for the quote
you offered. Please specify which ONE of them indicates, as you said,:

I just love how Microsofts 'you should use MDB to link to SQL Server
because it has less layers'.

That's the assertion for which I hope you can come up with some citation.
Thanks.

 

[aaron.kempf]

I'm still looking through archive.org

Sorry for the delay, sir

-Aaron

 

[BruceM]

ADPs have hundreds of improvements in Access 2007

Why so many? Were there problems?

And please note-- that MDB didn't get a single update from
2000-2007..

This article, which it is somewhat promotional, lists changes:
http://office.microsoft.com/en-us/access/HA100241851033.aspx

Another:
http://technet.microsoft.com/en-us/library/cc179181.aspx

A Google search will turn up many others. Maybe you have a different
definition of "updates" than most.

 

[aaron.kempf]

for years and years and years they said that 'ADP have less layers'.

So then when the MDB script kiddies had a turn at the wheel they just
changed the argument

-Aaron

 

[aaron.kempf]

Security
Although Access databases (using the Jet engine) can be password
protected and encrypted, these databases do not have the same level of
security as SQL Server or mainframe database systems. If data security
is critical, a SQL Server solution is the better choice. SQL Server
offers 128-bit encryption and storage in a remote location from the
user and application. Combined with Web services, SQL Server allows
distributed data in a controlled and highly secure manner.
Data Integrity
Similarly, data integrity and recovery is not as robust on file-based
databases using Jet, compared to SQL Server with its triggers,
transaction logs, and repair processes.
File server databases using Jet may become corrupt and require regular
maintenance to maintain optimal results. Even with maintenance, the
chance of failure is much higher than with SQL Server.
The Total Visual Agent (http://www.fmsinc.com/products/agent/) product
addresses the administrative needs of daily database maintenance
(compacts and backups), but it's not the same as the built-in features
of SQL Server.
Backups
Access databases (using the Jet engine) are easy to back up (copy
the .mdb file). However, these databases require user initiative,
unless an automated process or tool, like Total Visual Agent, is in
place.
If the Access database is open and the data is changing, it cannot be
backed up while users are in it. This is a major problem, if the
database is critical and used 24 hours a day, seven days a week.
The administrative tools for SQL Server have more features, compared
to Access. Backups can run anytime, even if users are active. This is
done through the use of transactions. Access supports transactions,
but it is limited compared to SQL Server.
Transaction Logs and Rollbacks
If you need to know who modified what data, and undo changes, SQL
Server's built-in features and triggers support this.
An Access application can try to replicate the tracking of changes by
managing user interaction with the data. However, it would require
programming and could not be managed at the core data level. Mistakes
in the application or other applications in contact with the Access
data could cause data changes that are not documented. There are also
no rollbacks in Access after a transaction is committed.
Network Bandwidth
A well designed application using SQL Server can significantly reduce
the amount of data moving across the network, because only the
requested records are passed from the database to the application.
File server databases pass the whole table (or at least the index)
across the network. This may not be significant for small files, but
performance suffers as the data grows.
Scalability
One Access database (using the Jet engine) is limited to 2 gigabytes
(GB). If a database exceeds that, the solution can't be entirely
solved by Access. Access databases also have problems with too many
simultaneous users. The number depends on what they are doing.
If there's a lot of data, SQL Server is the better choice. SQL Server
also supports more users and traffic, not only through its limited
bandwidth traffic, but also with the ability to improve performance,
by investing more in hardware through more memory, more CPUs, and more
computers. This option is not available for file server databases like
Access.
Related to scalability is the option of consolidating multiple Access
databases into one large SQL Server database. Although you may combine
several Access databases into one, if the size, security, or other
requirements exceed Access capabilities, SQL Server is ideal. Having
one large repository has the potential for using Business Intelligence
(BI) tools and Web publishing with significant business and
operational opportunities.

 

[George Hepworth]

Again, I'm not interested in assertions; I am interested in citations.


for years and years and years they said that 'ADP have less layers'.

So then when the MDB script kiddies had a turn at the wheel they just
changed the argument

-Aaron

 

[aaron.kempf]

http://msdn2.microsoft.com/en-us/library/aa833098(office.10).aspx
--------------
Provides efficient, native-mode access to a Microsoft SQL Server
database through the OLE DB component architecture. Acts as a front-
end to the SQL database.
--------------

http://msdn2.microsoft.com/en-us/library/aa139953(office.10).aspx
--------------
Access projects (.adp files) are a robust way of developing true
client/server applications by using Microsoft SQL Server or Microsoft
Data Engine (MSDE), and all right from the Access user interface. With
this technology, you can now natively connect to a SQL Server back-end
database and develop it right in Access.
--------------

http://msdn2.microsoft.com/en-us/library/aa139930(office.10).aspx

What Is an Access Client/Server Project?
--------------
While it may not be obvious at first glance, Microsoft Access 2000 is
actually two products in one:

The latest and greatest version of a time-tested product for
developing desktop and small workgroup database solutions that
use .mdb files and the Microsoft Jet database engine to manage data.
--------------
An all-new product for developing client front-end applications that
use OLE DB native-mode access to connect to SQL Server 6.5, SQL Server
7.0, or Microsoft Data Engine (MSDE) to manage a back-end database.
--------------
Database Server Advantages
The decision to use a client/server solution is driven primarily by
two factors: scalability and reliability. If your solution needs to
scale to serve more than 25 to 50 users, you should consider using a
client/server solution instead of a file-server solution. A file-
server database also has inherent reliability limitations because it
is maintained as a file in the file system, which can easily become
damaged if either the client or server computer (or the connection
between them) fails during a transaction or other operation that
writes to the database file. By isolating all database files under the
control of a database server such as SQL Server, the client/server
architecture can provide greater reliability and other advanced
features that can't be furnished by the file-server architecture, such
as the following:

Online backup
When you are using a database server, you can use an automatic
scheduler to back up your database without having to exclude users
from the database.

Durable transactions
SQL Server and MSDE log transactions so that updates made within a
transaction can always be recovered or rolled back to the last
consistent state if either the client or the server computer fails.
Although the Microsoft Jet database engine and .mdb files also provide
transactions, the transactions in .mdb files aren't managed by a
separate transaction log and can fail without recovery if the database
file becomes damaged.

Better reliability and data protection
If either a workstation or file server fails while an .mdb file is
being written to, the database may be damaged. You can usually recover
a damaged database by compacting and repairing the database, but you
must have all users close the database before doing so. This rarely
happens with a server database such as Microsoft SQL Server or MSDE.

Faster query processing
Using an .mdb file, regardless of where it is located, requires your
solution to load the Jet database engine locally to process queries on
the client. For large databases, this can involve moving a lot of data
over the network. In contrast, SQL Server runs queries on the server,
which is typically a much more powerful computer than the client
workstations. Running queries on the server increases the load on the
server more than would happen with an Access file-server solution, but
it can reduce the network traffic substantially--especially if users
are selecting a small subset of the data.

Advanced hardware support
Uninterruptible power supplies, hot-swappable disk drives, and
multiple processors can all be added to the server with no changes to
the client workstations.

Integrated Windows NT security
Both SQL Server and MSDE support using Windows NT(R) security accounts
to authenticate users who are logging on to a database. This means
that, unlike security for Access/Jet databases, if users are already
logging on to a Windows NT network, you can use their existing Windows
NT security groups and accounts to define permissions in your
database, as an alternative to creating and maintaining accounts on
the database server yourself.

Advanced server-side programming and support for business rules
Microsoft SQL Server and MSDE support a very feature-rich SQL dialect
called Transact-SQL. Used in conjunction with features such as
constraints and triggers, Transact-SQL allows you to define business
and security rules on the server that are enforced equally among all
users of the database. You can also use Transact-SQL to create stored
procedures that run on your server to provide flexible and secure
access to your data from any client.
------------------------------
http://msdn2.microsoft.com/en-us/library/aa139932(office.10).aspx
------------------------------
For ADP files, however, the data comes directly from SQL Server, and
Jet is never involved.
------------------------------
Microsoft Access databases (and the bulk of the examples in this
chapter) use the Microsoft Jet 4 OLE DB Provider. Microsoft Access
projects (ADP files) use the Microsoft OLE DB Provider for SQL
Server.
------------------------------
http://msdn2.microsoft.com/en-us/library/aa140039(office.10).aspx
------------------------------
An Access 2000 data project makes it possible for you to use familiar
Access tools to build SQL Server databases. When the Microsoft Office
2000 Developer Access Workflow components are installed, a data
project can be registered as a team solution and enhanced with
workflow processes to create and enforce business rules.
------------------------------
http://msdn2.microsoft.com/en-us/library/aa139973(office.10).aspx
------------------------------
Access projects (.adp files), which allow you to develop true client/
server applications from within the Access environment. Creating these
project files differs from the traditional file-server development
that Access developers have typically used, such as developing a
database application with the Microsoft Jet database engine and saving
all the database objects in a single .mdb file.














Furthermore, SQL 2005 increased performance from 10-59%.
This is on _TOP_ of existing tests that show that SQL 2000 outperforms
Access MDB in almost all tests.

Farm size SQL Server 2000
average RPS SQL Server 2005
average RPS Change
Small 75 97 +29%
Medium 131 198 +51%
Large 1015 1114 +10%
Extra-large 1638 1932 +18%
Extra-large, topics only 1148 1820 +59%
Extra-large, team sites only 1722 1610 -7%
Extra-large, home page only 1736 1750 +1%



http://www.datarevive.com/access_to_sql_server.php
[ Is the Access Jet Engine Dead? ]

Some background briefly ... Microsoft released the last version of the
Jet Engine Database (the underlying database engine that Access is
based on) with Office 2000 SR1, and Office 2002 (XP) retains this
'dead' engine. The strategic direction for Microsoft was to abandon
the Jet engine (MDB database) in favor of SQL Server in the year 2000.

However, many companies small and large continue to forge ahead with
complicated multi-user Access databases often to their detriment (in
terms of increased risks of database corruption, poor performance and
lack of any data security).

Due to the above reasons, we recommend to all clients with mission
critical database systems written with Microsoft Access and using the
Jet database (i.e. a database with MDB extension) be upsized/converted
to SQL Server and where necessary a new front end developed in
Microsoft Access.
---------------------------------------------
http://www.microsoft.com/technet/prodtechnol/sql/2000/deploy/accessmigration.mspx
---------------------------------------------
Microsoft Access developers generally consider a move to Microsoft SQL
Server for performance, security, and stability reasons. This process
is known as upsizing, and developers will find a number of key
differences while migrating from Access to SQL Server.

http://www.motobit.com/tips/detpg_Perfdata/
------------------------------------------------------
Aarons Note: Notice the 100ms performance improvement in opening a
connection.
This more than overcomes all of the MS execution time of the rest of
the queries combined.
------------------------------------------------------
http://www.microsoft.com/msj/0299/ado20/ado20.aspx
------------------------------------------------------
Hierarchical Cursors and Data Shaping
If you work with data, then it's very likely that you need to extract
it from multiple tables. In most cases, you utilize JOIN commands to
merge data from related tables, especially if you access relational
databases. Any recordset that originates from a JOIN command always
contains redundant information. For example, if you're interested in
all the books written by an author, you can join the Authors and the
Title Author tables (I'm referring to the Biblio and PUBS databases
here). In the returned record-set, the information about the author is
uselessly repeated for each row.
Eliminating redundant information becomes more important the more you
work with complex and nested JOINs, where hierarchical cursors allow
you to organize the recordsets with a tree-based logic. This process
is also called data shaping, and it can be accomplished in two ways.
You can use a shape language similar to SQL, or you can shape data
through high-level Visual Studio 6.0 companion tools. I'll provide an
example later on. For now let's have a look at the shape language.
In some respects, the shape language appears to be akin to the SQL
language.


SHAPE {select au_ID, Author from authors}
APPEND ( {select ISBN from [title author]}
AS chapter RELATE au_id TO au_id)


Basically, the SHAPE command defines a recordset, and the APPEND
clause adds a child recordset to it. In other words, a recordset can
be used as any other data type for a field (see Figure 6). Parent and
child recordsets are linked through a field-to-field relationship that
needs a name as well.
-------------------------------------------------
Microsoft Data Engine (MSDE)
MSDE is the new data engine for Microsoft and is our strategic
direction. MSDE is completely compatible with the SQL Server version
7.0 code base, enabling customers to write one application that scales
from a PC running the Windows 95 operating system to multiprocessor
clusters running Windows NT Server, Enterprise Edition.

Some of the technologies included in MSDE are as follows:

Dynamic Locking--This automatically chooses the optimal level of lock
(row, key range page, or table) for all database operations. It
maximizes the trade-off between concurrency and performance, resulting
in optimal usage. No tuning is required.
Unicode--This improves multilingual support.
Dynamic Self-Management--This enables the server to monitor and manage
itself, allowing for hands-off standard operations.
Merge Replication--This allows users to modify distributed copies of a
database at different times, online or offline, and the work is later
combined into a single uniform result.
MSDE incorporates technology from SQL Server 7.0. By using MSDE,
developers can later enable hundreds or even thousands of users to use
such SQL Server 7.0 features as the following:
-----------------------------------
http://msdn2.microsoft.com/en-us/library/aa140017(office.10).aspx
-----------------------------------
Enterprise requirements
If you are developing or using Access in an enterprise environment,
MSDE is the recommended data engine. Even if your current needs are
not at the enterprise level, using the Access front end with the MSDE
back end will help ensure that your database will be in the optimal
position for scaling as your business needs grow.

Enterprise applications require scalability, security, and robustness,
which can all be implemented with MSDE or SQL Server but not with Jet.
For example, if your application needs transaction support, even in
the event of a network, server, client computer, or client application
crash, you will want to use MSDE or SQL Server. Conversely, the Jet
engine does not support atomic transactions: It does not guarantee
that all changes performed within a transaction boundary are committed
or rolled back.
------------------------------------------
Requirement SQL Server (use MSDE if these are future requirements)
Microsoft Access (Jet)
Scalability
SMP support
No SMP support

Virtually unlimited number of concurrent users
Maximum of 255 users

Terabyte levels of data
2 GB of data

Transaction logging
No transaction logging

Business Critical
7X24 support and QFE
No 7X24 support

Point-in-time recovery
Recoverable to last backup

Guaranteed transaction integrity
No transaction logging

Built-in fault tolerance
No built-in fault tolerance

Security integrated with Windows NT
No integrated security with Windows NT

Rapid Application Prototyping Access is UI for both engines and offers
WYSIWIG database tools and built-in forms generation.
------------------------------------------
Number of Simultaneous Users (Performance)--SQL Server 7.0, the basis
for MSDE technology, can handle a very large number of simultaneous
users. Jet and MSDE are optimized for individual or small workgroup
solutions.
MSDE also has a performance advantage over Jet for large sets of data
and many simultaneous users. Because Jet is a file-server system, the
query processing must happen on the client. This involves moving a lot
of data over the network for large databases. MSDE runs that same
query on the server. This puts a larger load on the server, but can
reduce network traffic substantially, especially if the users are
selecting a small subset of the data.

If you are creating a new application for a small group of users, MSDE
or SQL Server will help your application scale in the future.

Advantage: MSDE and SQL Server for scalability
------------------------------------------
Features Jet MSDE
Heterogeneous joins X X
Top n and top n% queries X X
Validation rules X X
Default values X X
Triggers and stored procedures 0 X
Referential integrity through triggers 0 X
Declarative referential integrity X X
Engine-level cascading updates and deletes 0 X
Basic locking unit Row Row
Row locking on insert X X
Field-level replication X X
Custom code for replication conflict resolution X X
Scheduled replication X (Requires Microsoft Office 97, Developer
Edition) X
Built-in security X (File level read/write password or permissions
through OS) X
Built-in encryption X X
Distributed transactions .0 X
Dynamic backup and restore 0 X
Transaction log backups 0 X
Automatic Recovery 0 X
32-bit engine X X
Data capacity 2 GB per database 2 GB per database. SQL Server supports
TBs per database
-------------------------------------------------
Use Jet if:

You want the highest compatibility with Access 97 or earlier.
Your environment has a small number of simultaneous users.
You have very low resources, such as memory or disk.
Ease of use is a primary concern.
Use MSDE if:

You want to develop from a single code base, from a single user to
thousands of users.
You expect a future need for greater scalability.
You require easy merge replication with the central server.
You need the best security.
You need great reliability, such as transaction logging.
Your system is online 24 hours a day, 7 days a week.
You need stored procedures and triggers.
-------------------------------------------------------------------



Aarons Note - now I agree with most of this stuff.. But Access MDB is
_NOT_ easier to use than Access- specifically with the release of SQL
2000 and Access 2002, we got the ability to write functions, stored
procedures in design view. Ever since then; Access had no benefit in
ease of use.