Hi,

I intend to use DBISAM and EDB in common as both have their advantages.
So what would be the best wy to exchange data between these two. I would
love something like a TDBISAMtable.SavetoEDBStream and a
TEDBTable.SavetoDBISAMStream.

Arnd

Hi Arnd,

I think some way of exchanging data between the two systems would be a
good idea as well as I have some existing applications that use DBISAM
that I need to link to some new applications that I would like to use
ElevateDB for.

Chris Holland


Arnd Baranowski wrote:
> Hi,
>
> I intend to use DBISAM and EDB in common as both have their advantages.
> So what would be the best wy to exchange data between these two. I would
> love something like a TDBISAMtable.SavetoEDBStream and a
> TEDBTable.SavetoDBISAMStream.
>
> Arnd

Arnd,

<< I intend to use DBISAM and EDB in common as both have their advantages.
So what would be the best wy to exchange data between these two. I would
love something like a TDBISAMtable.SavetoEDBStream and a
TEDBTable.SavetoDBISAMStream. >>

The only way is to use something like this for EDB --> DBISAM:

http://www.elevatesoft.com/dbisam_faqt_22.htm

Since, both can be compiled into the same application, it will work just
fine.

For DBISAM --> EDB, you can just use one of the DBISAM migrator modules that
comes with EDB.

--
Tim Young
Elevate Software
www.elevatesoft.com

I am about to convert my application from DBISAM V1 to either DBISAM V4 or
EDB. What are the advantages of DBISAM V4 vs EDB ??? Since you mention
advantages I was curious. Thank you.

Neil Huhta






"Arnd Baranowski" <baranowski@oculeus.de> wrote in message
news:817DD463-20FC-4920-BD75-C9B3B6A700CF@news.elevatesoft.com...
> Hi,
>
> I intend to use DBISAM and EDB in common as both have their advantages. So
> what would be the best wy to exchange data between these two. I would love
> something like a TDBISAMtable.SavetoEDBStream and a
> TEDBTable.SavetoDBISAMStream.
>
> Arnd

Tim,

>
> The only way is to use something like this for EDB --> DBISAM:
>
> http://www.elevatesoft.com/dbisam_faqt_22.htm
>
> Since, both can be compiled into the same application, it will work just
> fine.
>

I thought something like that. However I would have prefered somehting
more elegant but I think it will do.


> For DBISAM --> EDB, you can just use one of the DBISAM migrator modules that
> comes with EDB.
>

Sounds good. I have a look at it.

Arnd

Neil,

EDB is the future and I will go for it.

However DBISAM V4 server architecture and what you can do with it is
simply incredible. You can write your own servers and easily move all
application inteligence (with little tricks) into. Up today I am not
sure whether we will be able to do the same with EDB.

DBISAMs deficit comes when it gets beyond 1-2 million records. Certain
operations get a bit unhandy, so with DBISAM we are always trying to
keep tables at max to this size. EDB operates nicely far, far beyond
this amount.

Knowing what you should not do and what you can do you can use both
databases for whatever you need. We for example use DBISAM with our
telecom companies business solution and manage to eveluate 100.000.000
calls wihtin 4 hours on windows multiprocessor systems with 4 DBISAM
servers and running 6 threads in parallel.

I do not know how complex your stuff is but if it is not then I
certainly would go for EDB solely.

Arnd

Huhtaman wrote:
> I am about to convert my application from DBISAM V1 to either DBISAM V4 or
> EDB. What are the advantages of DBISAM V4 vs EDB ??? Since you mention
> advantages I was curious. Thank you.
>
> Neil Huhta
>
>
>
>
>
>
> "Arnd Baranowski" <baranowski@oculeus.de> wrote in message
> news:817DD463-20FC-4920-BD75-C9B3B6A700CF@news.elevatesoft.com...
>
>>Hi,
>>
>>I intend to use DBISAM and EDB in common as both have their advantages. So
>>what would be the best wy to exchange data between these two. I would love
>>something like a TDBISAMtable.SavetoEDBStream and a
>>TEDBTable.SavetoDBISAMStream.
>>
>>Arnd
>
>
>

Neil

Just to throw my bit in. If you're still using V1 then you won't be using a lot of the goodies that came along later. One big thing this should mean is that the transition to ElevateB will be easier. Transitioning to V4 (I'm guessing since I went V2-V3-V4) won't be a major problem. The main difficulties that I remember was the alteration in the memory table from a true/false property to a pseudo path (\memory\table) and the switch to disallowing single quotes in favour of double quotes in some parts of sql. I'm sure there were more but those were the biggies that I remember.

If you go V1-V4 remember DBISAM is now "depreciated". Its still alive and well but Tim isn't promising much in the way of enhancements for the future (I'm not even sure about how long he's planning to keep it around).

ElevateDB is definitely faster in some areas and has the possibilities of lots of enhancements either by Tim or users writing their own bits. However, if you move to V4, start to use its goodies and then move to ElevateDB you will have a "not nice" experience so the best time is now.

If I had to sum up the differences (and remember its only my opinion) I'd say DBISAM easier to use, friendlier but still with oodles of features, ElevateDB a bit faster (a lot faster for text indexing), more powerful and extendible but harder to use.

Overall my advice would be to jump straight to ElevateDB.


Roy Lambert

> If I had to sum up the differences (and remember its only my opinion) I'd say DBISAM easier to use, friendlier but still with oodles of features, ElevateDB a bit faster (a lot faster for text indexing), more powerful and extendible but harder to use.
>
>
>
> Roy Lambert

How is it harder?

> How is it harder?

I do not agree. Personally I find EDB easier to use than DBISAM. The catalog
(Configuration database) needed some further explanation, but overall I am
more comfortable with EDB than I was with DBISAM.

And, unlike Roy, I do not have an issue with NULL     I am just teasing
Roy here a little bit.

But really, if I had to choose between DBISAM and EDB, my choice would be
EDB. Period.

Fons

Sanford,

<< How is it harder? >>

It's harder if a) you're coming from a non-SQL background and b) you're
really used to the way the code-based methods work in DBISAM for creating
and altering tables, etc.

For those that come from other database servers, however, it is probably
pretty stock-standard stuff that they're used to.

--
Tim Young
Elevate Software
www.elevatesoft.com