I have inherited a Delphi application and associated DBISAM tables, last Delphi  executable install was 2008.  I am setting up a development environment where I can re-write this system as we have no source code as the developer is long gone.  I have discovered that the DBISAM tables are in version 4.00 format.  

My question is - would it be best to use the lowest 4.XX version or the highest 4.XX version as a starting point for the development.  

My development will be in a modular fashion, so I will do let say inventory first and then other modules later, so there is the potential to have the existing application accessing tables and the new application accessing the same tables.  

Owen,

I assume this is using file-share access (and not the dbsrvr and C/S model).

I would suggest you use the same version as the old compiled app uses -
there has been at least 1 breaking change in v4 internal file handling
(specifically in 4.28) and you should not be accessing same table files
using old and new versions of the dbisam engine.

Might be tricky to figure out what build exactly the old version used -
if there is a dbsys utility from that time then its About dialog would
provide the DBISAM build number.

Mid 2008 you're likely looking at build 4.26 or such. It might make
sense to use the latest 4.27 build as that's the last release before the
change but see if you can narrow it down further.

Raul


On 4/17/2013 1:43 PM, Owen wrote:
> I have inherited a Delphi application and associated DBISAM tables, last Delphi  executable install was 2008.  I am setting up a development environment where I can re-write this system as we have no source code as the developer is long gone.  I have discovered that the DBISAM tables are in version 4.00 format.
>
> My question is - would it be best to use the lowest 4.XX version or the highest 4.XX version as a starting point for the development.
>
> My development will be in a modular fashion, so I will do let say inventory first and then other modules later, so there is the potential to have the existing application accessing tables and the new application accessing the same tables.
>

Owen,

<< My development will be in a modular fashion, so I will do let say
inventory first and then other modules later, so there is the potential to
have the existing application accessing tables and the new application
accessing the same tables. >>

If that's the case, then you have to use 4.27 or earlier.  At least until
you can recompile everything using 4.28 or higher.  This is from the 4.28
release notes:

"There is a new design for the BLOB reading/writing that is not compatible
with 4.27 or earlier. Therefore, it is extremely important that you do not
mix DBISAM 4.28 applications with DBISAM 4.27 or earlier applications.
Mixing the two versions can cause improper truncation of BLOB data, and that
includes using a 4.27 application on any data that has been updated by
DBISAM 4.28, even if it is not concurrently. The issue is that 4.27 and
earlier versions recylcle BLOB blocks on a per-block basis, whereas 4.28 and
higher versions recycle BLOB blocks on a per-row basis."

If you have any other questions, please let me know.

Tim Young
Elevate Software
www.elevatesoft.com

I downloaded the 4.25 release and the associated utilities.  When I installed the utilities on my development machine, and then looked at the help--->about, it gave me some info:  Version 4.25 (4.25 Build 7)  Copyright © 2007 Elevate Software, Inc.  All Rights Reserved

I think this is the general time frame of our last release; 2007.  When I look at the table version is said 4.00.  So, would it be pretty safe to be able to install these utilities on the server where I am do some utility functions?  Anything that I should watch out for?

There has been virtually no maintenance, other than an occasional backup that has been performed on the database since 2008.   Are there some things that I should do to help performance?  Optimize?  I thought there would be some form of compression that would reorder indexes etc.  The documentation that is contained in the utility function is pretty sparse.

Is there a better place to get more information?

Owen

>There has been virtually no maintenance, other than an occasional backup that has been performed on the database since 2008. Are there some things that I should do to help performance? Optimize? I thought there would be some form of compression that would reorder indexes etc. The documentation that is contained in the utility function is pretty sparse.
>
> Is there a better place to get more information?

Got to be careful with the phrasing here. There isn't much documentation cos DBSys and DBISAM don't do that much. Its a nice simple, easy to use, robust and pretty fast database and that's it. DBSys simply gives you an interface to do things without writing your own code.

There isn't a great deal of documentation because everything you need to know is in the DBISAM manual in the UI is pretty simple to follow.

What can be done to make your system more performant depends on what it does

If there have been a fair number of additions AND deletions from the database OPTIMIZE (in the Utilities menu) can help. It will remove the deleted items and pack the table. If the table is generally accessed via a particular index then select that one for the optimisation then the data will be physically organised in that sequence. Naturally no one else can be using the system when you start optimising things.

I don't know what the system does but you quote inventory so its possible that there's a wadge of data lying around that isn't in use and should be archived. If there's nothing built into the system for that it might be worth discussing with the powers that be what can safely be deleted and what needs to be retained. Can you for example create a copy of the database for historical purposes and then delete all transactions more than 7 years old and then delete all master records that don't have any transactions. Then optimise.  A smaller database is pretty much guaranteed to be faster


The only other thing that I can think of that might help you probably don't have the information for if you lack the source code. That is creating indices to speed up queries.


Roy Lambert [Team Elevate]

Owen,

<< I think this is the general time frame of our last release; 2007.  When I
look at the table version is said 4.00.  So, would it be pretty safe to be
able to install these utilities on the server where I am do some utility
functions? >>

With 4.x tables, you can install any release up to (and including) 4.27.
There's no need to use 4.25, and 4.27 will have a lot more bug fixes and
will work better than 4.25.

<< There has been virtually no maintenance, other than an occasional backup
that has been performed on the database since 2008.   Are there some things
that I should do to help performance?  Optimize?  I thought there would be
some form of compression that would reorder indexes etc.  The documentation
that is contained in the utility function is pretty sparse.
Is there a better place to get more information?  >>

Yes, the complete manual for DBISAM is here (segmented by development
environment):

http://www.elevatesoft.com/manual?category=dbisam

The help in the utilities assumes a certain level of knowledge already
provided by the core manuals.

If you have any other questions, please let me know.

Tim Young
Elevate Software
www.elevatesoft.com

Thanks everyone.  I will install the 4.27 and take it from there.   More questions to come I am sure.