I searched to forums and found some posts, but still I am not 100% sure of the steps needed to upgrade from 4.24 to 4.31.  My application connects to the dbsam server (client/server), but also accesses local tables without a server.  

It is as simple as replacing dbsrvr.exe and dbsys.exe out with the new ones?

Do I need to reinstall my Delphi 7 dbisam components and recompile my application?

I have 2 customers, one is going to keep running on 4.24, but the other will upgrade to 4.31.  So do I need to have 2 sets of dbisam components for each?

Thanks in advance

On 2/22/2013 4:29 AM, tonyt wrote:
>   It is as simple as replacing dbsrvr.exe and dbsys.exe out with the new ones?
Yes

> Do I need to reinstall my Delphi 7 dbisam components and recompile my application?
Yes

> I have 2 customers, one is going to keep running on 4.24, but the other will upgrade to 4.31.  So do I need to have 2 sets of dbisam components for each?
You can generally only have 1 set of components in installed in Delphi
so you can't have 2 versions so supporting both 4.24 and 4.31 will be
pain (unless you have 2 delphi environments).

Furthermore there are some breaking changes in 4.28 so to avoid any
issues i would suggest either upgrade both or neither (see release notes
for 4.28 for BLOB handling changes).

Why not upgrade to latest 4.34 ?

Raul

Tony,

<< I have 2 customers, one is going to keep running on 4.24, but the other
will upgrade to 4.31.  So do I need to have 2 sets of dbisam components for
each? >>

I wouldn't recommend this.  As Raul indicated, you should consider moving
both to 4.35, which is coming out in a few days.  It will be the most stable
build/release to use.

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

Tim Young
Elevate Software
www.elevatesoft.com

Thank you both for your replies.  

So just to clarify, if I replace the dbsrvr.exe file with new version and I don't recompile my application I am going to have issues?

Tim, on version 4.35, is it only bug fixes or are there new features on this as well?  


>>>
"Tim Young [Elevate Software]" wrote:

Tony,

<< I have 2 customers, one is going to keep running on 4.24, but the other
will upgrade to 4.31.  So do I need to have 2 sets of dbisam components for
each? >>

I wouldn't recommend this.  As Raul indicated, you should consider moving
both to 4.35, which is coming out in a few days.  It will be the most stable
build/release to use.

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

Tim Young
Elevate Software
www.elevatesoft.com

Tony,

<< So just to clarify, if I replace the dbsrvr.exe file with new version and
I don't recompile my application I am going to have issues? >>

If the dbsrvr is the *only* application accessing/updating the database
tables, then no, you won't have any problem with the BLOB changes that
occurred in 4.28.  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."

However, there are other client-side bug fixes that have been made since
4.21 that you're going to want to have also, such as this one:

http://www.elevatesoft.com/incident?action=viewrep&category=dbisam&release=4.29&incident=3169

<< Tim, on version 4.35, is it only bug fixes or are there new features on
this as well? >>

There are new features also.  From the release notes:

----------------------------------

There has been a change in the way that DBISAM opens files under Windows in
order to improve random file access performance. The end result is that
performance with very large tables should increase quite a bit after the
Windows file system has a chance to buffer the files to some degree.

The TDBISAMTable CopyTable method now includes an additional parameter that
indicates whether to copy the table data or not (default True).

The TDBISAMEngine component now includes additional trigger events for
capturing when transactions are started, committed, and rolled back:

StartTransactionTrigger
CommitTrigger
RollbackTrigger

----------------------------------

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

Tim Young
Elevate Software
www.elevatesoft.com