I want to apply a custom EngineSignature in a project I'm doing. I've played around with
the EngineSignature in a project with already-existing tables today, and it isn't working
as expected. Maybe I'm not understanding something...

I applied the custom signature like this:

procedure TdmApp.DataModuleCreate(Sender: TObject);
begin
   with DBISAMEngine1 do begin
     Assert(Active = False);
     EngineSignature := 'mySignatureString';
   end;
end;

I assumed then, that when my application attempted to open any existing table (all of
which were not created with the custom signature), an Exception would be thrown. But
nothing happens--the tables open normally. Is this expected behavior?

Mark Wilsdorf

Mark,

<< I assumed then, that when my application attempted to open any existing
table (all of which were not created with the custom signature), an
Exception would be thrown. But nothing happens--the tables open normally. Is
this expected behavior? >>

DBISAM allows for a given table to be opened if the signature is a) the
EngineSignature value or b) is the default EngineSignature value.    To make
sure that the tables use the newer EngineSignature, just optimize each one
using the TDBISAMTable.OptimizeTable method or OPTIMIZE TABLE statement.

--
Tim Young
Elevate Software
www.elevatesoft.com

Thanks for your help.

Mark Wilsdorf

A related question...

I remember seeing somewhere a comment that changes to DBSys might be required if built
with other than Delphi 5.

Well, I'm having no success building it with BDS 2006.

First thing I encountered is that there's a unit dependency of:  QuickRpt  (QuickReports,
I assume...which I don't have). So I commented that out, to see what else might happen,
and tried to compile again.

Next I encountered the error "Unit dbisamsv was compiled with a different version of
dbisamtb.EDBISAMEngineError." I see that dbisamsv is only supplied as a .DCU, so I won't
be able to get past this one.

Is anyone building DBSys with other than D5?

If so, what changes or workarounds are needed?

Thanks,

Mark Wilsdorf

Mark,

<< Next I encountered the error "Unit dbisamsv was compiled with a different
version of dbisamtb.EDBISAMEngineError." I see that dbisamsv is only
supplied as a .DCU, so I won't be able to get past this one. >>

I'll have to make some modifications to the builds to correct this one.
The issue is that we recently started including the dbisamtb.pas unit in the
builds, but when you re-compile your application it recompiles the
dbisamtb.pas unit with a different interface than that used in the original
compile.  So, we're going to have to stick the dbisamtb.pas unit in the
\source subdirectory instead.

--
Tim Young
Elevate Software
www.elevatesoft.com

"Tim Young [Elevate Software]" <timyoung@elevatesoft.com> wrote:

>>I'll have to make some modifications to the builds to correct this one. ...

My interest in the a custom engine signature idea was because I thought, as a last-minute
addition, it might add some casual data security to a project that will go out for public
testing soon.

But I don't want to send out the project with a custom engine signature if I don't have a
way to manually view customers' tables via an in-house DBSys, compiled to handle the
custom engine signature. So I guess for this project I'll be leaving that out, and just
warning users about data security for now.

I realize that the custom engine signature isn't really a security plan, anyway, and I
guess I'm going to have to "bite the encryption bullet" before this app gets to commercial
release.

Thanks,

Mark Wilsdorf
Flagship Technologies, Inc.
QuickBooks™ Add-Ons and Solutions You Can Use
http://www.goflagship.com

> Is anyone building DBSys with other than D5?

FWIW, I build it with D7. I think I had it working in D2007 too, after
adding the Reporting components from somewhere.

I have it in my build system for exactly the reason you want it for - that
little extra security against raw hacking. I also modified it so that for
some purposes it gets shipped, but not all the menus are enabled unless
you enter a password. I don't want people restructuring, but I do want it
there for myself if I have to remote support a PC.

/Matthew Jones/

Matthew,

<< I have it in my build system for exactly the reason you want it for -
that little extra security against raw hacking. I also modified it so that
for some purposes it gets shipped, but not all the menus are enabled unless
you enter a password. I don't want people restructuring, but I do want it
there for myself if I have to remote support a PC. >>

Just a general note - this is one good thing about ElevateDB that many
people don't realize.  It ships with Public and Administrators roles by
default, which means that you can ship the default EDB Manager or let them
download it from our site without any worries.  Just set up the
Administrator password that your application uses and don't give out the
password to the customers, and add another general user for "everyday" use
that can't do anything "bad".   And this works with both local/multi-user
and ElevateDB Server installations.

--
Tim Young
Elevate Software
www.elevatesoft.com

TVM. That'll be that scary catalog thing? One thing I really like about
DBISAM is that (for some of my apps) the users can just delete the
database directory and my app creates it all again using function calls.
IIRC there is a file needed for the catalog in ElevateDB, and I think I
need to Read the FM to learn why that isn't scary. I suppose it could be
in a resource anyway.

/Matthew Jones/

Matthew,

<< TVM. That'll be that scary catalog thing? >>

Actually it's the scary configuration file thing.   The scary catalog thing
is something different.

<< One thing I really like about DBISAM is that (for some of my apps) the
users can just delete the database directory and my app creates it all again
using function calls. >>

ElevateDB does that also.  In fact, it will even create an empty catalog if
one doesn't exist in the database directory.  It also automatically creates
the table files if they don't exist, which is something that DBISAM can't
even do.

<< IIRC there is a file needed for the catalog in ElevateDB, and I think I
need to Read the FM to learn why that isn't scary. >>

It isn't scary because it eliminates a major point of corruption that was an
issue with DBISAM.  Storing the metadata in the same files as the data means
that the files are constantly being updated, thus furthering the possibility
that Windows could screw up the data *and* metadata if the machine goes
down.  Any updates to the ElevateDB catalog are done in a manner that allows
for complete recovery of the original catalog in the case of corruption.

<< I suppose it could be in a resource anyway.>>

What kind of resource are you referring to here ?

--
Tim Young
Elevate Software
www.elevatesoft.com