Reliability of Access (JET) Over a LAN?

Thread view:

Enable EMail Alerts

Start New Thread

Thread rating:

Grant Schenck - 11 May 2006 17:03 GMT

Hello,

I'm looking to build a solution. It is a simple .NET app which will use a
network shared JET database. The database will consist of a single table
with a single field containing a telephony number. There will be 26 clients
each of which will periodically query to see if a specific number is in the
table (once a minute or so.) In addition, they will periodically use Access
or possibly a simple .NET app to add/delete/view the list of numbers. It is
possible that they may have more then one person adding and that the adding
would happen at the same time as client users are doing lookups.

So, my manager came back with this KB article:

http://support.microsoft.com/?scid=kb;en-us;303528

And statements to the effect that Access is unreliable over a LAN. While
the article does refer to some issues, I see them more as a CYA on MS' part
rather then a fundamental condemnation of using JET over a LAN. The
article is by no means cut and dry.

I last used Access about 10 years ago in a similar sized Networked app and
it was fine. My manager is pushing to use MSDE or build our own server on
top of JET. This all seems like an overkill.

So, what in the concensus of JET/Access developers? Is JET fundamentally
flawed when used over a network or is it basicly pretty reliable when used
mainly for reading and with relativly low query rates and with good backup
proceedures.

Thanks!

Signature

Grant Schenck

Reply to this Message

Sylvain Lafontaine - 11 May 2006 20:31 GMT

I don't want to enter the discussion of the reliability of JET over the LAN;
however, as you want to use .NET as the frontend, I really don't see any
reason why you would want to use it as your backend database.

Using JET as the backend makes sense only if you want to use Access as the
frontend; otherwise you will end up with all the disadvantages of JET/Access
and none of their advantages. For example, Access gives you the possibility
of having pessimistic locking (if someone can see this as an advantage) but
you can't use this with a bound .NET form.

IMHO, if you want to go with .NET, you should forget about Access/JET.

Signature

Sylvain Lafontaine, ing.
MVP - Technologies Virtual-PC
E-mail: http://cerbermail.com/?QugbLEWINF

> Hello,
>
[quoted text clipped - 27 lines]
>
> Thanks!

Reply to this Message

Grant Schenck - 11 May 2006 21:10 GMT

OK, my requirements are:
- Run over a LAN.
- Client are C# .NET
- Would like "Access like" front end to allow DB updating.
- Would like to avoid true DB server and hassle of care and feeding.

What would you recommend for the database technology?

Signature

Grant Schenck
http://grantschenck.tripod.com

>I don't want to enter the discussion of the reliability of JET over the
>LAN; however, as you want to use .NET as the frontend, I really don't see
[quoted text clipped - 39 lines]
>>
>> Thanks!

Reply to this Message

Sylvain Lafontaine - 11 May 2006 22:22 GMT

«
- Client are C# .NET
- Would like "Access like" front end to allow DB updating.
»

Choose between one of these two but not both. If you choose C#.NET, your
frontend would be anything but like "Access like".

If you choose C#.NET, SQL-Server Express 2005 would be my suggestion as the
BE.

Signature

Sylvain Lafontaine, ing.
MVP - Technologies Virtual-PC
E-mail: http://cerbermail.com/?QugbLEWINF

> OK, my requirements are:
> - Run over a LAN.
[quoted text clipped - 46 lines]
>>>
>>> Thanks!

Reply to this Message

Grant Schenck - 12 May 2006 01:55 GMT

I'm not following you.

Why can't I have a C# .NET application which reads from Access tables and
also allow people to directly view and add/delete records to the table from
Access?

There are certainly plenty of articles about getting at Access DBs from .NET
apps...

Regarding SQL Server Express 2005, I assume that it is a true server vs. a
shared file system?

Thanks,

Signature

Grant Schenck

> «
> - Client are C# .NET
[quoted text clipped - 57 lines]
>>>>
>>>> Thanks!

Reply to this Message

Sylvain Lafontaine - 12 May 2006 05:05 GMT

Yes, you can have a C#.NET that can read and update Access tables and there
are a lot of other technologies that can do the same, for example ASP.
However, nobody here will tell you that you code an ASP page the same way as
you are using Access.

This is probably a misunderstanding about the exact meaning of « "Access
like" front end ».

If for you, ASP is an "Access like" front end; then the same is true for C#
.NET.

For your last question, SQL-Server Express 2005 is a true server like the
standard or the enterprise editions of SQL-Server 2005 but with a limitation
of 4 Gigs for the size of the database.

Signature

Sylvain Lafontaine, ing.
MVP - Technologies Virtual-PC
E-mail: http://cerbermail.com/?QugbLEWINF

> I'm not following you.
>
[quoted text clipped - 70 lines]
>>>>>
>>>>> Thanks!

Reply to this Message

Grant Schenck - 12 May 2006 12:24 GMT

So, if I can use C# .NET to read and update Access tables then that sounds
like the appropriate technology for my application.

As I stated at the onset, this is a very small multi-user application (26
user) who do a single lookup approx once a minute. Any actual updating of
the records in the DB will be done via Access.

So, my question is:

Is there any reason I shouldn't use Access as the underlying database for
this application?

Signature

Grant Schenck
http://grantschenck.tripod.com

> Yes, you can have a C#.NET that can read and update Access tables and
> there are a lot of other technologies that can do the same, for example
[quoted text clipped - 85 lines]
>>>>>>
>>>>>> Thanks!

Reply to this Message

Sylvain Lafontaine - 12 May 2006 17:04 GMT

If you put aside any performance issue, the only reason not to use Access
would be that Access is extremely sensitive to any weakness in the network.
Even the smallest disturbance can lead to a corrupt database.

Unless you don't mind having a corrupted database from time to time, you
must have a rock solid network to use Access on a LAN.

For some users, security and a full transactionnal model can also be of some
relevance to their choice.

Signature

Sylvain Lafontaine, ing.
MVP - Technologies Virtual-PC
E-mail: http://cerbermail.com/?QugbLEWINF

> So, if I can use C# .NET to read and update Access tables then that sounds
> like the appropriate technology for my application.
[quoted text clipped - 99 lines]
>>>>>>>
>>>>>>> Thanks!

Reply to this Message

Grant Schenck - 12 May 2006 17:57 GMT

OK, that is kind of what I was looking for.

What exactly is going to expose me to the issues? Specifically, is a read
only query where the client issuing the query crashes or looses its network
connection is it possible for the DB to be corrupted?

Thanks,
--
Grant Schenck

> If you put aside any performance issue, the only reason not to use Access
> would be that Access is extremely sensitive to any weakness in the
[quoted text clipped - 110 lines]
>>>>>>>>
>>>>>>>> Thanks!

Reply to this Message

Sylvain Lafontaine - 12 May 2006 19:52 GMT

For a reading only query? No, I don't think so: for JET, locking semaphores
are kept in a separate file, the .LDB file, so any possible corruption for a
reading query will be made on the .LDB file, not the MDB file.

Signature

Sylvain Lafontaine, ing.
MVP - Technologies Virtual-PC
E-mail: http://cerbermail.com/?QugbLEWINF

> OK, that is kind of what I was looking for.
>
[quoted text clipped - 120 lines]
>>>>>>>>>
>>>>>>>>> Thanks!

Reply to this Message

Grant Schenck - 18 May 2006 14:28 GMT

Thanks! That's what I figured. At the end of the day, given that usually
there will be one updater accessing the MDB over a LAN the application
doesn't really expose me anymore then a any user accessing an MDB over a LAN
(which must happen a lot!)

Signature

Grant Schenck

> For a reading only query? No, I don't think so: for JET, locking
> semaphores are kept in a separate file, the .LDB file, so any possible
[quoted text clipped - 128 lines]
>>>>>>>>>>
>>>>>>>>>> Thanks!

Reply to this Message

Sylvain Lafontaine - 18 May 2006 18:47 GMT

Even if the risk are low in your case, I still don't see why you want to use
a MDB file as the backend instead of SQL-Server Express.

It's like seeing someone keeping asking if it's really dangerous to drive a
car without wearing the security belt and receiving advice like « Well, if
you don't drive to much hours per week, the risks are low. » .

Signature

Sylvain Lafontaine, ing.
MVP - Technologies Virtual-PC
E-mail: http://cerbermail.com/?QugbLEWINF

> Thanks! That's what I figured. At the end of the day, given that usually
> there will be one updater accessing the MDB over a LAN the application
[quoted text clipped - 132 lines]
>>>>>>>>>>>
>>>>>>>>>>> Thanks!

Reply to this Message

Sylvain Lafontaine - 12 May 2006 20:00 GMT

You should also ask yourself:

« Is there any reason I shouldn't use SQL-Server Express as the underlying
database for this application? »

Signature

Sylvain Lafontaine, ing.
MVP - Technologies Virtual-PC
E-mail: http://cerbermail.com/?QugbLEWINF

> So, if I can use C# .NET to read and update Access tables then that sounds
> like the appropriate technology for my application.
[quoted text clipped - 99 lines]
>>>>>>>
>>>>>>> Thanks!

Reply to this Message