I'm going to be deploying an app that will use DBISAM, and the tech
support people are going to need a basic data viewer tool for maintaining
the thing, just in case. Obviously DBSys is the sensible thing to use. I'd
like to know how other people handle this. Do you just take it as-is, or
do you recompile to "brand" it a little. Do you put it in source control
and rebuild for each DBISAM update you do, or is it all more random?

How robust is DBSys with other versions of DBISAM - if I'm using a newer
version of DBISAM and they use an older DBSYs for maintenance, will there
be problems?

All thoughts on this appreciated.

/Matthew Jones/

We always match our client, server, dbsys and restructure utilities for
latest release.  I don't let the client run unless they are matched.

Running latest DBsys with older (but same primary) version would probably be
ok.

PS We have to 'brand' our DBsys as we running a header encryption which
protects our data from random access. ie We recompile
DBsys with our encryption and we also put a login password (Panel that hides
everything unless they key in correct password).  O
Only the authorized pick person at the site can run it.  Should there ever
be an issue, we can change the password. on next release.

Some ideas to consider.

Donat.


"Matthew Jones" <mattjones@cix.co.uk> wrote in message
news:memo.20060918154316.3332B@nothanks.nothanks.co.uk...
> I'm going to be deploying an app that will use DBISAM, and the tech
> support people are going to need a basic data viewer tool for maintaining
> the thing, just in case. Obviously DBSys is the sensible thing to use. I'd
> like to know how other people handle this. Do you just take it as-is, or
> do you recompile to "brand" it a little. Do you put it in source control
> and rebuild for each DBISAM update you do, or is it all more random?
>
> How robust is DBSys with other versions of DBISAM - if I'm using a newer
> version of DBISAM and they use an older DBSYs for maintenance, will there
> be problems?
>
> All thoughts on this appreciated.
>
> /Matthew Jones/

"Matthew Jones" <mattjones@cix.co.uk> wrote in message
news:memo.20060918154316.3332B@nothanks.nothanks.co.uk...
> I'm going to be deploying an app that will use DBISAM, and the tech
> support people are going to need a basic data viewer tool for maintaining
> the thing, just in case. Obviously DBSys is the sensible thing to use. I'd

Careful, DBSYS is not just a "data viewer", users can make changes, delete
records and even whole tables, etc. I would try to get a good solid
definition of "maintaining the thing", or you'll find yourself scratching
your head over an out of balance caused by somebody "fixing" the database
outside your application. And if all you want is a table viewer, you can
whip one out in a few minutes, without all the added features of DBSYS.

Robert

Hi Matt,

> I'm going to be deploying an app that will use DBISAM, and the tech
> support people are going to need a basic data viewer tool for maintaining
> the thing, just in case. Obviously DBSys is the sensible thing to use. I'd
> like to know how other people handle this. Do you just take it as-is, or
> do you recompile to "brand" it a little. Do you put it in source control
> and rebuild for each DBISAM update you do, or is it all more random?
>
> How robust is DBSys with other versions of DBISAM - if I'm using a newer
> version of DBISAM and they use an older DBSYs for maintenance, will there
> be problems?

I never give DBSys to users.  I write my own utilites that allow them to
manage the databases.  That way I can control what they can and can't
do, basically protecting them from themselves.

Regards,

SteveG

Thanks all. I think I'll take the DBSys source, then build it with a few
mods to stop the advanced items without a password. Most of the time the
database maintenance has been done by me, but there are some key people
who need to be able to do things. At the end of the day my app is designed
so that the support people can just delete the databases and restart and
it will work (the app is a data transport system so the databases only
hold transit information). The previous version of this app used MSDE but
that was a nightmare, and we used EMS SQL Lite to manage it (the free one
can be deployed easily on client sites without license issues). The new
version, about to go live, uses DBISAM to remove all the hassle SQL Server
gave us. I could moan about the 3 days the support guy took trying to get
an side-by-side installation of MSDE on a system where the admin password
wasn't known and the C drive was too full. With the DBISAM version it will
now be an app install on D drive and off we go. Bliss.

Anyway, I need something powerful but I'll password restrict it for
general use. [fx: later] That was easy. About 10 mins to rebuild and
customise to suit. Great tool.

/Matthew Jones/