Hi Tim,
I want port some applications written with Dbisam 4 to EDB in immediate
future and I have some questions..:
In a very diffuse installed application, sometimes people damage databases;
ok....I can repair it; But sometimes autoincrement values in tables give a
wrong result generating big random numbers; with this error customer
continue its work and give use the damaged tables with a lot of records that
have the wrong value in autoincrements; The question is this: suffer EDB in
the same manner of DBISAM when tables are damaged, or autoincrement starting
point is stored differently for avoid this problem?
Another question: what about single file (optional) feature? I known that
you dont' like this feature, and I agree with you; But sometimes this
feature is very important; For ex. : I have 400 customers that work on their
PCs (database with 30 tables in 3 directories, all tables related), and
later, when the work is complete, all data must send to a central server
that perform some important operations; Sometimes files are overwritten
(wrong user input, bad renaming operation, user that copy/past some
directories in others, etc..) because is hard to control all data that must
send and reside SEPARATELY for every customer on the server; With a single
file instead, customer signed as AX001 must send only the file DB_AX001 that
contain all, simply; I have only
In this scenario single file is a better solution that separated; Please
consider it, because now there are even some extra files(catalogs, etc).
Don't forget partial fetching features that permits use to work comfortable
via real SQL instead tables with big databases;

Good Job,
Stefano Monterisi

Stefano Monterisi wrote:
>  Sometimes files are overwritten
> (wrong user input, bad renaming operation, user that copy/past some
> directories in others, etc..) because is hard to control all data that must
> send and reside SEPARATELY for every customer on the server; With a single
> file instead, customer signed as AX001 must send only the file DB_AX001 that
> contain all, simply; I have only
> In this scenario single file is a better solution that separated; Please
> consider it, because now there are even some extra files(catalogs, etc).

Stefano,
     If you want to send just one file, then have your program zip the
selected files and send the zip file. Not only are you sending only 1
file, but it is also compressed and can be encrypted. I use VclZip but
there are other products out there too that work within Delphi. You can
then use something like RTC (RealThinClient) to send the file to your
server without the user having to lift a finger!

Dave

Hi Dave,
thanks for your help....

I already use VclZip from release 1.0 (Delphi 2?), and already send one
ziped files (encrypted) to the server (RemObjects), and already my user
don't lift a finger....all is automatic since 1997.......
But during the job, user (and especially "genius expert" user) copy, past,
backup and restore, move folders because they don't have a better things to
do. All ok, but sometimes, they move PARTIAL piece of database (for ex. city
lookup table or more vital customer table lookup) that is very dangerous,
because it's diffcult to understand what problem they have really, when the
application hang-up.
In a one-file conf. I am sure that all tables are related correctly; I they
restore o backup, ALL tables are involved; if they delete the file....all is
reset
This because some applications go everywhere and I don't known the user and
cannot control it.
I can control only its final result on the server (when is too late.....).
(sorry for my english)
Good job, Dave


"Dave Harrison" <daveh_18824@spammore.com> ha scritto nel messaggio
news:B63F11BC-2CE9-467F-8275-05517FA25F80@news.elevatesoft.com...
> Stefano Monterisi wrote:
>>  Sometimes files are overwritten (wrong user input, bad renaming
>> operation, user that copy/past some directories in others, etc..) because
>> is hard to control all data that must send and reside SEPARATELY for
>> every customer on the server; With a single file instead, customer signed
>> as AX001 must send only the file DB_AX001 that contain all, simply; I
>> have only
>> In this scenario single file is a better solution that separated; Please
>> consider it, because now there are even some extra files(catalogs, etc).
>
> Stefano,
>      If you want to send just one file, then have your program zip the
> selected files and send the zip file. Not only are you sending only 1
> file, but it is also compressed and can be encrypted. I use VclZip but
> there are other products out there too that work within Delphi. You can
> then use something like RTC (RealThinClient) to send the file to your
> server without the user having to lift a finger!
>
> Dave
>

Stefano,

<< But sometimes autoincrement values in tables give a wrong result
generating big random numbers; with this error customer continue its work
and give use the damaged tables with a lot of records that have the wrong
value in autoincrements; The question is this: suffer EDB in the same manner
of DBISAM when tables are damaged, or autoincrement starting point is stored
differently for avoid this problem? >>

This problem is not solvable since EDB (and DBISAM) both have to assume that
any valid integer value is valid for an IDENTITY column (autoinc).  You'll
have to manually reset the values for an IDENTITY column followed by a
REPAIR TABLE execution in order to fix this issue.

<< Another question: what about single file (optional) feature? I known that
you dont' like this feature, and I agree with you; But sometimes this
feature is very important; For ex. : I have 400 customers that work on their
PCs (database with 30 tables in 3 directories, all tables related), and
later, when the work is complete, all data must send to a central server
that perform some important operations; Sometimes files are overwritten
(wrong user input, bad renaming operation, user that copy/past some
directories in others, etc..) because is hard to control all data that must
send and reside SEPARATELY for every customer on the server; With a single
file instead, customer signed as AX001 must send only the file DB_AX001 that
contain all, simply; I have only In this scenario single file is a better
solution that separated; Please consider it, because now there are even some
extra files(catalogs, etc). >>

I'm sorry, but neither DBISAM nor EDB will include a single-file format for
local or multi-user sessions (non-C/S).  It is possible that the EDB
enterprise server have may single-file databases, but that is because it
will always have exclusive access to the databases that it manages.

<< Don't forget partial fetching features that permits use to work
comfortable via real SQL instead tables with big databases; >>

DBISAM and EDB already support only fetching the necessary rows on the
client.  What you're referring to is simply returning control the client
prior to the completion of the execution of the SQL statement, which is a
completely different thing and is only useful for very specific types of
queries.

--
Tim Young
Elevate Software
www.elevatesoft.com

Hi Tim,

> This problem is not solvable since EDB (and DBISAM) both have to assume
> that any valid integer value is valid for an IDENTITY column (autoinc).
> You'll have to manually reset the values for an IDENTITY column followed
> by a REPAIR TABLE execution in order to fix this issue.

Yes, but I ask if  EDB manage it differently from Dbisam, "inside the
table", so to avoid the problem of creation of big integer into damaged
table. For ex. if you have changed its position in the header.....
>

> I'm sorry, but neither DBISAM nor EDB will include a single-file format
> for local or multi-user sessions (non-C/S).  It is possible that the EDB
> enterprise server have may single-file databases, but that is because it
> will always have exclusive access to the databases that it manages.

??? Can I have some information on enterprise server?

> DBISAM and EDB already support only fetching the necessary rows on the
> client.  What you're referring to is simply returning control the client
> prior to the completion of the execution of the SQL statement, which is a
> completely different thing and is only useful for very specific types of
> queries.

Yes.
But very specific types of queries may be a simple grid with a lot of master
records on the main screen of application. My users can see the form only
after several seconds; I must use a table for show it
immediately...............

Stefano Monterisi

Stefano,

<< Yes, but I ask if  EDB manage it differently from Dbisam, "inside the
table", so to avoid the problem of creation of big integer into damaged
table. For ex. if you have changed its position in the header..... >>

I'm not sure what you're asking.  It doesn't really matter where the next
autoinc value is stored.  Because it is updated on a per-row insert/update
basis, it has the potential to be subject to corruption if the machine goes
down.   Once it is corrupted, DBISAM and EDB really can't do anything with
it since it is always possible that the value is valid.

<< ??? Can I have some information on enterprise server? >>

We don't have anything concrete yet, but it will basically be a higher-end
EDB Server with better concurrency, transaction control, and large memory
support.

<< But very specific types of queries may be a simple grid with a lot of
master records on the main screen of application. My users can see the form
only after several seconds; I must use a table for show it
immediately............... >>

Are you using RequestSensitive:=False ?  If so, then you need to use
RequestSensitive:=True, and the rows should appear immediately.

--
Tim Young
Elevate Software
www.elevatesoft.com

Hi Tim,

> I'm not sure what you're asking.  It doesn't really matter where the next
> autoinc value is stored.  Because it is updated on a per-row insert/update
> basis, it has the potential to be subject to corruption if the machine
> goes down.   Once it is corrupted, DBISAM and EDB really can't do anything
> with it since it is always possible that the value is valid.

Uhmmm.....I now control that autoinc not > 10000000 for ex. for fire
corrupted autoinc.....
There is a "native" event that permits me to understand that the autoinc is
crazy? (???)
(this is the only problem that I have with Dbisam, when the damaged table is
recoverable...)
>
> << ??? Can I have some information on enterprise server? >>
>
> We don't have anything concrete yet, but it will basically be a higher-end
> EDB Server with better concurrency, transaction control, and large memory
> support.

Ok, we talk about it when betas are available....

> << But very specific types of queries may be a simple grid with a lot of
> master records on the main screen of application. My users can see the
> form only after several seconds; I must use a table for show it
> immediately............... >>
>
> Are you using RequestSensitive:=False ?  If so, then you need to use
> RequestSensitive:=True, and the rows should appear immediately.
>

Tim, I don't except this answer from you....:-;
........ naturally I intend queries that don't permits sensitive result
set!!!!!....

Another question: there are news on .net provider?

Thanks in advance,

Stefano Monterisi



> Tim Young
> Elevate Software
> www.elevatesoft.com
>
>

Stefano,

<< Uhmmm.....I now control that autoinc not > 10000000 for ex. for fire
corrupted autoinc..... There is a "native" event that permits me to
understand that the autoinc is crazy? (???) (this is the only problem that I
have with Dbisam, when the damaged table is recoverable...) >>

I suppose we could add something to the REPAIR TABLE to allow for this.
Something like a MAX IDENTITY VALUE clause.

<< Tim, I don't except this answer from you....:-; ....... naturally I
intend queries that don't permits sensitive result
set!!!!!....>>

Sorry, it's hard to break the habit of covering the basics.  In that
case, I would then recommend that you use queries that can return sensitive
result sets, and use calculated fields or lookups to provide any values from
other tables on an as-needed basis.  One of the things that currently isn't
allowed in EDB, but may be soon, is the ability to define computed/generated
columns in a table that refer to columns in other tables.

<< Another question: there are news on .net provider? >>

It's almost ready to go, and basically waiting on 1.06 to get released.
Same goes for the VCL.NET support.

--
Tim Young
Elevate Software
www.elevatesoft.com