Adam,

Luckily, I will be converting an old database from another vendor to
DBIsam and there are no custom units or DB specific code at this time.
I will be able to at least start with DBIsam v4.22b4 and get a good
deal of the basic work done. The client is a government entity and any
DB which charges for licenses is a "no-go". Luckily, no queries were
used either, just tables. It is a pretty basic app which they need
"beefed up".

Thanks for your input.

--
Regards,
Jan Ferguson


Adam H. wrote:

> Jan,
>
> Something else you may need to consider is the component names, that
> will be changing. I know for me personally, I will need to do a
> little more work, as I have many custom procedures of my own that
> refer to TDBISAMTables / Queries, that will need to have new units
> rewritten for TEDBTables (or whatever).
>
> Personally, I can't just do a simple search/replace as I will
> mostlikely have some older program still running V4, whilst others
> running V5 when I upgrade.
>
> It's not a huge deal, but it is something worth considering if you
> have your own custom units with procedures for DBISam, where you will
> require it to remain the same for some applications, and changed for
> upgraded applications.
>
> If I'm missing something simple here - someone please step in.
>
> Cheres
>
> Adam.

Adam

Tim Young [Elevate Software] wrote:

> happens.  I simply will not release the product until it is ready, so the
> release date will always suffer before the quality.
>

Customers will tolerate late software; they will not tolerate bad
(bug-riddled, broken, etc.) software.


Mark

Mark


When did you stop using Windows, Word, Excel etc

Roy Lambert

> When did you stop using Windows, Word, Excel etc

Roy! You bet me to it!!!!  

Roy Lambert wrote:
> Mark
>
>
> When did you stop using Windows, Word, Excel etc
>
> Roy Lambert
>

Tim Young [Elevate Software] wrote:

> happens.  I simply will not release the product until it is ready, so the
> release date will always suffer before the quality.
>
Dear Tim ;;;
the new dbisam 5 or what to call ElevateDB ,is it a single flat file database like mdb of Access ???
reply by email if necessary ...
friendly yours.. NK

"NK SOFT SYSTEM" <aymen_k2003@yahoo.ft> wrote in message
news:F47BA8CD-226C-4C71-8D5F-2048144279AA@news.elevatesoft.com...
> Tim Young [Elevate Software] wrote:
>
>> happens.  I simply will not release the product until it is ready, so the
>> release date will always suffer before the quality.
>>
> Dear Tim ;;;
> the new dbisam 5 or what to call ElevateDB ,is it a single flat file
> database like mdb of Access ???
> reply by email if necessary ...
> friendly yours.. NK

It has been mentioned on these groups that it will not be a single-file
system.

Besides the existing v4 three-file structure per table, there is an
additional catalog file for each database.

NK<

<< the new dbisam 5 or what to call ElevateDB ,is it a single flat file
database like mdb of Access ??? reply by email if necessary ... >>

As indicated by Johnnie, it will be just like DBISAM with 3 files per table,
and one additional catalog file per database.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim,

<<As indicated by Johnnie, it will be just like DBISAM with 3 files per table,
and one additional catalog file per database.>>

Is it possible to combine the index file into its table file like in NexusDB? The single catalog file
per table and seperate file for each table is excellent.



--
Manfredt Kavetu

Tim,

<<As indicated by Johnnie, it will be just like DBISAM with 3 files per table,
and one additional catalog file per database.>>

Is it possible, in later versions of ElevateDB, to combine the index file into its table file
like in NexusDB? The single catalog file per database and seperate file for each table is excellent.

While we are still on this subject, is the description of each table in the catalog or in the table
header? I know there was a discussion in this newsgroup about this and some people
felt the description of the table should be in each table, but my feeling is that the description
of each table should be in the catalog - and I think this will have some advantages like
perhaps faster table restructuring?



--
Manfredt Kavetu