>We are looking at alternatives to the Microsoft Jet 3.5 Engine for small
>scale multi user work.

>The kind of work we are  doing involves between up to 8 users over a LAN
and
>is a general mix of decision support plus some addition / updating of data.
>Data also has to be moved (at times) between different databases.

>A key requirement is that the system be largely maintenance-free (there
will
>be no skilled DBA's on site), will be a good 'all-round' performer and
>stable (ie will not easily suffer corruption).

> HI.

> We are looking at alternatives to the Microsoft Jet 3.5 Engine for small
> scale multi user work.

> The kind of work we are  doing involves between up to 8 users over a LAN and
> is a general mix of decision support plus some addition / updating of data.
> Data also has to be moved (at times) between different databases.

> A key requirement is that the system be largely maintenance-free (there will
> be no skilled DBA's on site), will be a good 'all-round' performer and
> stable (ie will not easily suffer corruption).

> The system will handle several hundred personnel record-sets each year from
> several sources (basically an on-line db and manual entries).  Each
> record-set is a collection of records  related to an individual (detailed
> personal info, how he/she interfaces with the organisation and various
> performace data).  Each set will be added and maintained during the lifetime
> of the person (in the organisation) after which specific attributes will be
> transferred (electronically) to a separate system (entirely separate at
> present, but this may change) which will be used for tracking and
> development.

> There will be 3 groups of users with privileges ranging from being able to
> select, insert and amend from only two of the tables to an admin who will
> have nearly full rights.

> We have made a multi-user prototype using VB4 (Enterprise), Jet 3.5 and DAO
> (have also tried RDO 2.0) and have been generally impressed by the
> performance but are *very* wary of realeasing the system with Jet as a
> central rdbms - we have had rather mixed results with previous versions (2,
> 2.5
> and 3.0)  : performance and irrecoverable corruption have been
> problems (especially in a situation where unskilled users can switch off
> machines)

> Available infrastructure is reasonable : a 10Mb Ethernet and most of the
> machines are 133 Pentiums  (there are two 66MHz 486 workstations as well)
> and the OS is mixed NT4 (WS) and W95.

> We have examined two other database engines; a shared file and a
> client-server.

> (1)  We examined the Microrim Oterro db Engine with ODBC/RDO 2.0.  This is a
> shared file setup and Microrim (the makers) claim that it is a high
> performance engine positioned between Jet and a C/S setup.  It seemed
> reasonable but we have absolutely *no* other experience of this (nor were we
> able to get any examples of current installations or comparisons from
> Microrim).

> Has anybody else used this engine ?

> (2)  We have been very impressed with the SOLID Server client-server RDBMS
> (from SolidTech). This is a 'lightweight' client-server engine.  It has the
> 'management' that we are looking for (automated backups, versioning,
> transaction log and automatic recovery), seems robust and is claimed to be
> 'maintenance-free'.  This last is important to us.
> Performance is reasonable but, with our small number of connections over our
> LAN, we did not see any improvement over Jet 3.5  (we tried two basic
> setups :  Solid tables attached to local Jet 3.5 db's at each user-site  and
> RDO 2.0 accessing the Solid db directly from VB interfaces at each
> user-site.)
> Solid can use only the rdUseODBC cursor and the ForwardOnly and Static
> resultsets of RDO 2.0 so it's possible that this limits the performance a
> bit - we found that tables attached to local Jet db's gave equal or better
> performance  (better connection handling ?)

> Again, I'm looking for other people's experience of this dbms.

> I would be very grateful for any comments given regarding Jet, Oterro and
> Solid.

> Thank You,

> ZeroWhy not MS SQL Server?

>We are looking at alternatives to the Microsoft Jet 3.5 Engine for small
>scale multi user work.

>The kind of work we are  doing involves between up to 8 users over a LAN
and
>is a general mix of decision support plus some addition / updating of data.
>Data also has to be moved (at times) between different databases.

>A key requirement is that the system be largely maintenance-free (there
will
>be no skilled DBA's on site), will be a good 'all-round' performer and
>stable (ie will not easily suffer corruption).

>The system will handle several hundred personnel record-sets each year from
>several sources (basically an on-line db and manual entries).  Each
>record-set is a collection of records  related to an individual (detailed
>personal info, how he/she interfaces with the organisation and various
>performace data).  Each set will be added and maintained during the
lifetime
>of the person (in the organisation) after which specific attributes will be
>transferred (electronically) to a separate system (entirely separate at
>present, but this may change) which will be used for tracking and
>development.

>There will be 3 groups of users with privileges ranging from being able to
>select, insert and amend from only two of the tables to an admin who will
>have nearly full rights.

>We have made a multi-user prototype using VB4 (Enterprise), Jet 3.5 and DAO
>(have also tried RDO 2.0) and have been generally impressed by the
>performance but are *very* wary of realeasing the system with Jet as a
>central rdbms - we have had rather mixed results with previous versions (2,
>2.5
>and 3.0)  : performance and irrecoverable corruption have been
>problems (especially in a situation where unskilled users can switch off
>machines)

>Available infrastructure is reasonable : a 10Mb Ethernet and most of the
>machines are 133 Pentiums  (there are two 66MHz 486 workstations as well)
>and the OS is mixed NT4 (WS) and W95.

>We have examined two other database engines; a shared file and a
>client-server.

>(1)  We examined the Microrim Oterro db Engine with ODBC/RDO 2.0.  This is
a
>shared file setup and Microrim (the makers) claim that it is a high
>performance engine positioned between Jet and a C/S setup.  It seemed
>reasonable but we have absolutely *no* other experience of this (nor were
we
>able to get any examples of current installations or comparisons from
>Microrim).

>Has anybody else used this engine ?

>(2)  We have been very impressed with the SOLID Server client-server RDBMS
>(from SolidTech). This is a 'lightweight' client-server engine.  It has the
>'management' that we are looking for (automated backups, versioning,
>transaction log and automatic recovery), seems robust and is claimed to be
>'maintenance-free'.  This last is important to us.
>Performance is reasonable but, with our small number of connections over
our
>LAN, we did not see any improvement over Jet 3.5  (we tried two basic
>setups :  Solid tables attached to local Jet 3.5 db's at each user-site
and
>RDO 2.0 accessing the Solid db directly from VB interfaces at each
>user-site.)
>Solid can use only the rdUseODBC cursor and the ForwardOnly and Static
>resultsets of RDO 2.0 so it's possible that this limits the performance a
>bit - we found that tables attached to local Jet db's gave equal or better
>performance  (better connection handling ?)

>Again, I'm looking for other people's experience of this dbms.

>I would be very grateful for any comments given regarding Jet, Oterro and
>Solid.

>Thank You,

>Zero

>My only reservations with Access 8 are its lack of robustness and future
>scalability issues.  Otherwise it would do the job for the present.

>>Is Access sooo unreliable in a small multi-user enviroment?  We have
>>many users using Access 2.0 in single user enviroments (or network
>>environments with exclusive databases), and have experience little
>>problems with corruption - nothing that could be fixed without using
>>repair and compact.

>That's interesting. Which Network O/S do you use?

>Regards,
>Darren

>Generally Novell - but only using an Access database opened
>exclusively, as mentioned above.

> [snip]

> >My own researches on a (rather faster)  100Mb LAN showed that Access 8 can
> >give very good performance for a small scale setup.  However scalability is
> >zilch and I have (personally) known of many problems with Access - often
> >relating to corruption of the db (and unless these unskilled users who are
> >doing *other* jobs can remember to to do a backup then the data is sometimes
> >trashed)

> [snip]

> >... I support about 20 users of Access
> >databases, 2 of whom have repeatedly trashed systems through carelessness.

> [snip]

> >My only reservations with Access 8 are its lack of robustness and future
> >scalability issues.  Otherwise it would do the job for the present.

> Is Access sooo unreliable in a small multi-user enviroment?  We have
> many users using Access 2.0 in single user enviroments (or network
> environments with exclusive databases), and have experience little
> problems with corruption - nothing that could be fixed without using
> repair and compact.

> We have been planning to use Access is several small multi-user
> applications, less than five users at a time, segregating high
> transaction activity into posting files (locked tables).  Plan to use
> Access 97 (or 8) - Jet 3.  Is this such a bad idea?

> Steven

> Steven R. Zuch wrote

> >>That's interesting. Which Network O/S do you use?

> >Generally Novell - but only using an Access database opened
> >exclusively, as mentioned above.

> Thought so. You might find that if you try NT instead of Novell, suddenly
> you get all the corruption problems.

> Regards,
> Darren

>> [snip]

>I know personally of a group here locally in Atlanta that had Access
>deployed on a series of laptop machines.  Number of field units was in
>the hundreds.  They had a huge problem with support calls with the
>deveopers shouldering most of the blame.  They switched to Sybase SQL
>Anywhere and the support calls plummeted.  Personally I just had a power
>supply die in my main work machine over the weekend.  I was working on a
>project for client and they rather stupidly have insisted upon using
>Access.  Well, the db was corrupt.  Unfortunately when getting at the db
>from VB it did not report the db as being corrupt, just took the app
>down with an access violation in one of the dao dlls.  So it looked like
>the app was at fault.  Got into Access and everything seemed fine.  It
>wasn't until I opened one particular table that Access reported the
>problem.  I'm seriuosly considering getting the first version of this
>software out and then dumping the client.  I've already told then I will
>not respond to support calls that involve the failure of Access, but
>based upon my experience this weekend I have the {*filter*} feeling that I'm
>going to get hit by support calls that really are Access that are going
>to be blamed on the app.  (By the way, I had error trapping in the VB
>routine that was failing on the dao call.  Didn't make any difference.
>This one thing I just love about MS code - it tends to fail in ways that
>you can do precious little about.)

>DBA-Duties are normally only to make backups. You can skip this, but - I
>think it is better to show the people how o  do this.

>We use it currently in one place with 1Gb of data. One table has 3.5
million
>rows, works like butter.

>Just does not scale up very good. Practical user-limit seems to be around
>30.

>Have a look.

>Thomas TOmiczek
>Network Manager
>SIRECO INTERNET SERVICES GmbH

>>I know personally of a group here locally in Atlanta that had Access
>>deployed on a series of laptop machines.  Number of field units was in
>>the hundreds.  They had a huge problem with support calls with the
>>deveopers shouldering most of the blame.  They switched to Sybase SQL
>>Anywhere and the support calls plummeted.

>Are they still using Access 97 as the front-end and reporting tool ?

>I guess you are saying that Access 97 Jet 3.5, even run in a
>single-user environment with databases opened exclusively, is very
>prone to corruption.  I have not had that same bad experience with
>Access 2 Jet 2.0.

>> Personally I just had a power
>>supply die in my main work machine over the weekend.  I was working on a
>>project for client and they rather stupidly have insisted upon using
>>Access.  Well, the db was corrupt.  Unfortunately when getting at the db
>>from VB it did not report the db as being corrupt, just took the app
>>down with an access violation in one of the dao dlls.  So it looked like
>>the app was at fault.  Got into Access and everything seemed fine.  It
>>wasn't until I opened one particular table that Access reported the
>>problem.  I'm seriuosly considering getting the first version of this
>>software out and then dumping the client.  I've already told then I will
>>not respond to support calls that involve the failure of Access, but
>>based upon my experience this weekend I have the {*filter*} feeling that I'm
>>going to get hit by support calls that really are Access that are going
>>to be blamed on the app.  (By the way, I had error trapping in the VB
>>routine that was failing on the dao call.  Didn't make any difference.
>>This one thing I just love about MS code - it tends to fail in ways that
>>you can do precious little about.)

>My experience with Access 2.0 databases opened *exclusively* have been
>very good.  Very little corruption, regardless of the physical
>location (e.g. on a file server or local hard disk drive).  My limited
>use of Access 97 has not yet shown major corruption problems.

>It just seems so inconsistent and illogical that the most popular
>desktop database, made by the largest software company, used by so
>many users, is so terrible in a single-user, desktop, environment.