Currently I am working on a product that used DBISAM as the DB engine, however as we scale our application to more users and it get more
bloated with data the limitations of our DB design are becoming apparent.

These limitations are primarily born out of things that DBISAM doesn't do (and Elevate does!) like Triggers, Referential Integrity etc..

However we're really struggling to tear ourselves away from DBISAM because of the way it works. We like that it's file based and we can roll our
own server (and we do). All our applications can work in server mode connecting to our own flavour DBISAM server or they work directly with the
files (if they are pointed to the relevant directory) because the engine code is compiled directly into them.

I can't determine if ElevateDB will allow us the same level of flexibility. Essentially we want to be able to roll our own simple server (using native
compiled code) and apps must be able to work both with our server and directly with the DB files.

Can you please enlighten me?

- Paul.

Paul


ElevateDB supports both file/server and client/server, its all written in Delphi so you should be OK. There will be a few points to be wary of, mainly associated with the sql:2003 compliance. The move to catalog rather than table based operations has a few minor consequences.

The most significant changes (in my opinion) are:

NULL <> emptystring
data is no longer RTRIMed on loading to the database
overlength string fields raise an exception rather than being trimmed
case sensitivity is now controlled by COLLATE rather than UPPER/LOWER
full text indexing has changed a bit, and if you try and search on unindexed fields you get an exception
INTERVAL for date and time arithmetic (I have creative things planned for the inventor of this involving piano wire and gonads)
the way the memory database works has changed
SELECT INTO has gone
scripts are different - the simple statement by statement stuff is still sort of there but there's a whole new language here.
IF EXISTS has gone
you can no longer just copy a table to one side and work on it

The worst effect of the new architecture is that if I want to do a quick bit of testing I now have 4 components to stick on a form and hook up.

If you're allowing mixed f/s and c/s access one thing you have to do is use UNC throughout and go though the same database - its easier and safer.

There are a lot of positives moving to ElevateDB but there is a bit of learning needed unless you're a mainstream sql user as well as a DBISAM user.

Roy Lambert

Thanks for that Roy.

I don't think I'm going to have an issue with the sql:2003 compliance as I have experience with both sql server (since WAY back when ) and a
smattering of Oracle experience.

I'm a little confused by the line:
<quote>
If you're allowing mixed f/s and c/s access one thing you have to do is use UNC throughout and go though the same database - its easier and
safer.
</quote>

Do you mean UNC paths need to be used to access database files as "files" rather than use the server?

One thing I forgot to mention is that my company is thinking of a re-write owing to the product needing to evolve. The re-write is probably going
to be .Net mainly because employing Delphi programmers is becoming increasingly difficult. Secondly because Delphi seems to have lost its way
over the years and isn't quite the flagship it once was, but that's another post

Also can you roll your own server as you can do in DBISAM by adding the TDBISAMEngine component to an application?

- Paul

Paul,

<< Do you mean UNC paths need to be used to access database files as "files"
rather than use the server? >>

No, what he means is that you need to use UNC paths when accessing databases
through a file-sharing arrangement where the client application resides on a
different machine than the databases themselves.  The reason for this is
that database paths are defined in the configuration file in ElevateDB, and
the configuration file must reside in a common location that all client
machines can access.   Therefore, the path specified for the database must
be valid for all client applications, and UNC is the best way to accomplish
that.

If you simply want to have other applications on the same machine as the
ElevateDB Server accessing the databases, such as is the case with web
applications, then you don't need to worry about this since those
applications can use the same drive letters, etc. as the ElevateDB Server.

<< One thing I forgot to mention is that my company is thinking of a
re-write owing to the product needing to evolve. The re-write is probably
going to be .Net mainly because employing Delphi programmers is becoming
increasingly difficult. Secondly because Delphi seems to have lost its way
over the years and isn't quite the flagship it once was, but that's another
post >>

The only limitation there is that you cannot create a custom ElevateDB
Server in .NET as of this time.  You still have to use Delphi to customize
the ElevateDB Server, or roll your own.

<< Also can you roll your own server as you can do in DBISAM by adding the
TDBISAMEngine component to an application? >>

Yes, absolutely.  It works exactly the same way.

--
Tim Young
Elevate Software
www.elevatesoft.com

Thanks Tim,

<quote>
The only limitation there is that you cannot create a custom ElevateDB
Server in .NET as of this time.
</quote>

Is there a timeframe for this as this is kind of an important feature for us as our current DBISAM server is also our application comms server too?

- Paul

Paul

>I don't think I'm going to have an issue with the sql:2003 compliance as I have experience with both sql server (since WAY back when ) and a
>smattering of Oracle experience.

That will be very helpful - it was a nightmare for me since I'd only used sql once and that was as part of an evaluation exercise when we went for PICK.

>Do you mean UNC paths need to be used to access database files as "files" rather than use the server?

Nope. Its down to the fact that you can no longer drop a table/query on a form and set its databasename to the directory you have to set it to the database. If the catalog has a database FRED with a path C:\alocaldatabase then you'll have to have a second database in the configuration file pointing at the same tables for remote access eg \\server\cdrive\alocaldatabase.. Since these operations now take place in the configuration file you can get into difficulties if you try and drop/create/alter a database eg whilst someone else is using it.


>employing Delphi programmers is becoming increasingly difficult.

interesting

>Secondly because Delphi seems to have lost its way
>over the years and isn't quite the flagship it once was, but that's another post

I've pretty much decided to freeze my environment at D2006. I can see nothing I want from D2009 so I'll see what the future brings.

>Also can you roll your own server as you can do in DBISAM by adding the TDBISAMEngine component to an application?

No reason, apart from having to write code, why not, and its engine, session, database and table/query

Roy Lambert

Paul,

<< Is there a timeframe for this as this is kind of an important feature for
us as our current DBISAM server is also our application comms server too? >>

Not really, since there are limitations in .NET that are preventing using it
in such a way.

Is there any reason that you can't continue to use Delphi for the server
modifications ?

--
Tim Young
Elevate Software
www.elevatesoft.com

Hi Roy:

> I've pretty much decided to freeze my environment at D2006. I can see nothing I want from D2009 so I'll see what the future brings.

The D2006 ide would crash numerous times for me (some bug related to
..dsk files I think) whereas the D2009 has been much more stable.  That
alone was enough for me to upgrade.

I kind of like the separate build configurations that it has also.  Not
sure if that was added in D2007 or D2009 though.

Cheers,

Dale

<<Is there any reason that you can't continue to use Delphi for the server modifications ?

Yes, The company I work for is looking to drop Delphi all together due to the reasons cited. We're looking to move away from Delphi and it's IDEs
altogether. Moving probably to Visual Studio and C#.

<< Not really, since there are limitations in .NET that are preventing using it in such a way.

This is a disspointment. ElevateDB ticks all the boxes apart from this one.

Thanks for taking the time to respond.

- Paul