Am considering using VB3 (after all the reports of bloated code, slowness
and trouble with VB4 16-bit) for a large project on a Novell network and
WFW 3.11, using Access 2.0 data files and the "compatibility layer."
Customer insists that this be 16-bit, so 32-bit VB4 isn't an option.

There have been postings here re. VB4 not being able to save projects on
Novell networks.  Can VB3 projects save OK on Novell networks?

Other postings talk about problems with data integrity with Access.  Is
Access the problem or just using Access 2.0 data files w/ VB3 & the
compat. layer?  Does critical data really get lunched regularly or is this
the isolated experience of a few users?

Would like to use config. above for a critical project for a large client,
but would appreciate reports (good and bad) from anyone who has already
attempted to do this.  You can either reassure me or save me a lot of
trouble.  Thanks.

Steve Young
Young Computing

I've never had a problem saving VB3 projects onto a mapped drive on a
Novell network.  I run VB3 at work under WIN/OS2, so if it works there
I am sure it will work under 'real' Windows!

I don't have that much experience with Access databases and VB3, but
am working on a project using a setup similar to which you are looking
at.  For a large number of users I would think that you would want to
look for a better database and get to it through ODBC from VB3.
Access can't lock single records on the database, it lock a page at a
time (4K I believe), so if there are a large number of updates being
done I would think you could run into real problems, although probably
only performance waiting around for the record to be freed up, them
maybe worrying about overwriting someone elses changes.

But, like I said, I am no expert.  Hopefully some Access and VB gurus
will give you (and me!) more information.

Hope this helps some,

Mark

Web page: http://www.novia.net/~markh

VB3 works fine with Novell networks.

I have used VB3 with Access 2.0 databases for a long time with very few
problems -- the rate of database corruption in Access files was
significantly lower than the rate on similar networks performing similar
tasks with different database formats. The databases were used
concurrently by up to 20 people at a time for extended periods and ranged
in size from 15MB to a 550MB monster file (transaction city).
Unfortunately, there was noticable performance problems as the file size
grew. It wasn't BAD, but it was visible...

--j.

Yes they can.. I've been doing that for a while.

I have quite a large application which uses Access 2.0 compat. layer,
and the ONLY time i had problems was when i called older dated .DLL's
(ie older Novell NETWARE.DLL etc.) which were buggy which caused
Windows to hang and corrupt the database.