!!!Don't use the BDE with Paradox for commercial applications!!!
Lutz Weder
We tested BDE 5.2 with our well known example to create a corrupt file
(" .. other than header ..."): It's the same result, the BDE 5.2
produces a corrupt index file although we did report this bug in 2000!
WARNING: To all professional programmers - don't use the BDE with
Paradox format for commercial applications with large tables. Switch to
SQL or CodeBase, Advantage and so on! For Delphi and C++ there is a good
BDE replacement with CodeBase (www.sequiter.com).
We should forbid by decision of a court the shipping of the BDE with
Delphi, C Builder and Paradox. We reported this dramatic bug to Borland
already in 2000. Borland knows that all and even though they ship the
BDE for lots of money with their products and announce the "high speed
database drivers dbExpress and Borland Database Engine for ... Paradox
..." (this is a translation from the german Delphi 6 Professional
distribution) e. g. with Delphi 6.
All injured developers should take proceedings against Borland for
claims of damages!
Let's do something for our rights and against Borland!!!
Lutz Weder
A. Kladogenis
it works fine...
A. Kladogenis
"Lutz Weder" <wede...@t-online.de> wrote in message
news:3B7B7C80...@t-online.de...
Lutz Weder
"A. Kladogenis" schrieb:
> What do you mean "large tables". I have use it with tables of about 80MB and
> it works fine...
Here is an older article from us to show the problem:
-----------------------------------------------------
We created the table art2 new in Delphi 5 without use of the Database Desktop.
We used only Delphi commands:
In a Delphi form we placed a Table component and a button. In the button's
OnClick-method is the code to create the table with it's structures and index
structures and after them we filled it with the 328,031 records.
(328,031 is the number where a customer of us get problems).
Most important for this example: BDE settings level 5 and blocksize 4096 before
running the example program!
With level 7 or blocksize 32kB this example works, but other tables causes
trouble. We can give you examples to create invalid tables with level 7 and
blocksize 32kB!
----------------
procedure TForm1.Button1Click(Sender: TObject);
var
i: Longint;
begin
{ existing table not overwrite }
if not Table1.Exists then begin
with Table1 do begin
{ the table-component may not be active }
Active := False;
DatabaseName := 'HWDAT';
TableType := ttParadox;
TableName := 'art2';
with FieldDefs do begin
Clear;
with AddFieldDef do begin
Name := 'MANDANT';
DataType := ftSmallInt;
end;
with AddFieldDef do begin
Name := 'ARTNR';
DataType := ftString;
Size := 20;
end;
with AddFieldDef do begin
Name := 'LIEFERANT';
DataType := ftString;
Size := 4;
end;
with AddFieldDef do begin
Name := 'KURZTEXTA';
DataType := ftString;
Size := 40;
end;
end;
with IndexDefs do begin
Clear;
with AddIndexDef do begin
Name := '';
Fields := 'MANDANT;ARTNR;LIEFERANT';
Options := [ixPrimary];
end;
end;
CreateTable;
showMessage('Here the new table is built!');
end;
end
else begin
showMessage('table art2 exists, exit!');
exit;
end;
Table1.Open;
for i := 10000001 to 10328031 do // ARTNR should always have 8 digits
begin
Table1.Insert;
Table1.FieldByName('MANDANT').AsInteger := 1;
Table1.FieldByName('ARTNR').AsString := IntToStr(i);
Table1.FieldByName('LIEFERANT').AsString := 'ABCD';
Table1.FieldByName('KURZTEXTA').AsString :=
'1234567890123456789012345678901234567890';
Table1.Post;
if i = 10100000 then
showMessage('100000 appended');
if i = 10200000 then
showMessage('200000 appended');
if i = 10300000 then
showMessage('300000 appended');
end;
Table1.Close;
end;
---------------
After creating the table we can browse it with the Database Desktop or open in
in tableview in Paradox - it's always the same result: Corrupt file - other than
header.
===========================================================
Please, use a hexeditor to check the art2.PX file. At the offset 21,000 (Hexa)
begins the first invalid block!!!
There are two invalid blocks immediate one after the other.
That is the place where browsing of the table or cursor movement doesn't work.
===========================================================
We know that e.g. an additional field of A20 makes the table o.k., but could
everyone definitive say, if it works with e.g. 800,000 records? No!
The example art2 we don't need in practice. It should give you the possibility
to create a corrupt table and it should be a support for you (for Borland) to
find the errors!
Because we discussed that problem detailed in the Corel Newsforum Paradox 8 we
got already tips to change the index structure, use a autoincrement key and so
one. We checked that whith other tables and also with level 7 and blocksize
32kb. We could always create examples that were corrupt.
Regards
LutzWeder
Jeff Overcash (TeamB)
entries (as a matter of fact I double the number created) with no corruption
problems at all.
System W2K SP2, D6, BDE 5.2
Lutz Weder wrote:
--
Jeff Overcash (TeamB) I don't think there are any Russians
(Please do not email And there ain't no Yanks
me directly unless Just corporate criminals
asked. Thank You) Playing with tanks. (Michael Been)
Lutz Weder
"Jeff Overcash (TeamB)" schrieb:
> Your code didn't reproduce here. D6 + BDE 5.2 was able to create all the
> entries (as a matter of fact I double the number created) with no corruption
> problems at all.
>
> System W2K SP2, D6, BDE 5.2
>
We can't believe that, but we can't check it because we use WIN98 SE.
The example produces a corrupt index under WIN95, WIN98, WIN NT and LINUX (with
Paradox 9 and BDE 5.11).
The error occurs with BDE 4, 5.11 and 5.2
Lutz Weder
Bill Todd (TeamB)
Win2k Pro and cannot reproduce the problem.
--
Bill
(TeamB cannot answer questions received via email)
Lutz Weder
did you really use Paradox level 5 and blocksize 4096?
During creating of the example table there is no error shown.
The error occurs if you browse the table in the Database desktop or
Tableview in Paradox.
Browse it to the bottom and release the scrollbar. You will get the
message: "Table corrupt - file other than header".
Lutz
Aether
don't know if this is related to your problem, but the index file also
turned out to be crosslinked. That was under Win98SE and has not occured yet
under Win2K (I recently upgraded).
Bill Todd (TeamB)
exactly as you described. I'll zip the table and mail it to you if you would
like to see it.
Jeff Overcash (TeamB)
the newly created ~600,000 record table (I doubled the size you originally
posted) and everything scrolled fine.
--
Gunnar Haršarson
same error as you "Corrupt file - other than header" scrolling to the end of
the table both using database desktop and database explorer. I can test this
under Delphi 6 and Windows NT at my work.
Gunnar.
"Lutz Weder" <wede...@t-online.de> wrote in message
news:3B7B9654...@t-online.de...
Jeff Overcash (TeamB)
Pierre le Riche
Back in 1996-1997 we invested a lot of money in developing a multi-user
client management system running on the BDE and Paradox. It was a total
disaster from a data integrity point of view. If a machine on the network
crashed, or you got a power outage on one of the workstations, the database
almost always got damaged. There was no way we could guarantee the integrity
of our clients' data.
The situation was so hopeless that we had to withdraw the product from the
market and do a rewrite running on MSSQL Server. Our company lost a lot of
money in that learning experience. I remember becoming quite furious after I
saw a promotional video for Paradox soon after - touting it as everything it
wasn't.
There should be a big red sticker on the box that says: "Do NOT use Paradox
tables for commercial purposes".
Pierre le Riche
"Lutz Weder" <wede...@t-online.de> wrote in message
news:3B7B7C80...@t-online.de...
Gunnar Haršarson
not the main problem here. Thank you.
Gunnar.
Gunnar Haršarson
SP6 and also Delphi 6 using BDE 5.2 and Win2k SP1. And the result in all
cases the same error "Corrupt file - other than header".
Gunnar.
Jeff Overcash (TeamB)
due to excessive over quoting (which you did).
--
Anders E. Andersen
"Lutz Weder" <wede...@t-online.de> skrev i en meddelelse
news:3B7CF6CA...@t-online.de...
> Bill,
>
> did you really use Paradox level 5 and blocksize 4096?
>
> During creating of the example table there is no error shown.
>
> The error occurs if you browse the table in the Database desktop or
> Tableview in Paradox.
> Browse it to the bottom and release the scrollbar. You will get the
> message: "Table corrupt - file other than header".
ATN! This is a bug in Database desktop! We observed the same problem here
many times. The table is not really defective.
I agree though that the paradox database should only be used for hobby
programming it is simply not stable enough for commercial programs.
Anders E. Andersen - EBC products - Denmark
Anders E. Andersen
> To all developers who use the BDE with Paradox:
>
> We tested BDE 5.2 with our well known example to create a corrupt file
> (" .. other than header ..."): It's the same result, the BDE 5.2
> produces a corrupt index file although we did report this bug in 2000!
The error is in Database Desktop. The table is not really defective. We have
had the same problem with our software and thought for a long time that the
tables were corrupt. We only found out last weekend when we worked on
another serious problem that there really wasn't anything wrong with the
table.
The other problem is described in the a previous posting with the
subjectline 'Critical problem using master/detail with large tables' and is
related to using key based filtering together with non-keybased filtering on
large pdx tables.
Gunnar Haršarson
"Anders E. Andersen" <and...@strato.dk> wrote in message
news:3b80c3e6_2@dnews...
> The error is in Database Desktop. The table is not really defective. We
have
> had the same problem with our software and thought for a long time that
the....
The error is not only in the Database desktop. If you try the code from Lutz
Weder you will also get the error in Database explorer and worse if you use
a dbgrid control in Delphi and browse the table to the end you also get the
same error.
Gunnar.
David R. Robinson
Ditto... This thread is irrelevant because Borland isn't going to
update the BDE to fix the numerous bugs in Paradox that have existed for
years.
Paradox tables are too easily corrupted. You should not use Paradox
except maybe for single user systems.
David R.
Dennis Santoro
there on the BDE and Paradox. Lots of custom ones too. Paradox and the BDE
can be used safely. Even for large databases. Not for everything. But we
have large aps running in LAN and WAN environments on Paradox and very
rarely experience corruption. In every case we have been able to trace the
corruption to the network components or bad user behavior, not the BDE or
its design. You do have to be very careful about having a good
normalization. Best to use all meaningless integer keys and foreign key
links. You also have to make sure you have a good backup scheme in case you
do get corruption.
But we, and many others, have exceeded the size of Lutz's stuff. His problem
is using the wrong tool for the job or inefficient design. Depends on your
point of view. If he redesigned the indices he can get it to work. But he is
unwilling to do so. So then he simply needs to use a different tool. An
excerpt from the thread where Lutz posted this in the Corel groups
(cnews.corel.com in the group corel.wpoffice.paradox9):
---------- begin excerpt ----
> We want to preserve other developers from the same problem we got with our
customers -
the
> Paradox database does not work with large amounts of datas.
Paradox DOES work with large amounts of data. But it does not work with
large amounts of data in files with huge indices of concatenated alpha
fields and huge number of fields. In my archive I found one of the example
table structures you posted as
MANDANT S *
ARTNR A20 *
LIEFERANT A4 *
KURZTEXTA A40
File-type: Paradox 5, blocksize 4kB, langdriver:'ascii'ANSI, no secondary
index BDE 4.0,
level 5,
bloc-size 4096 file-size roughly 21MB supposing 328.031 sets
Now you are limiting yourself to about 32000 values in Mandant to begin with
although with the concatenation this might not be a problem But then you add
the other 2 concatenated values. You key just got huge. Why you can not use
a single long int key and then a secondary index on the other fields is
beyond me. There are folks out there with much larger tables than 21 MB
(myself included) who do not experience corruption on any sort of regular
bases.
You also state in one message:
"we shortened the field ARTNR from A20 to A12 and the example is o.k., but
we can't do that, because there are articles with 20 digits! If we add an
additional
field with A20 in the structure (not in index), this example is also o.k."
So if you were to change your index, the problem would go away. It is the
classic case of
"Doctor, it hurts when I hit myself with this hammer." So don't hit yourself
with that hammer. I appreciate that you warn folks about the potential for
problems with large, concatenated alpha keys. That is VERY different from
saying don't use the BDE and Borland should be sued. You know the problem.
You know how to avoid it. If you want something that works other than the
way the BDE does, buy it or build it.
----------- end excerpt ---
So, the issue is not the BDE but what to use it for and it certainly has
been, and can continue to be, used quite successfully. But not the way Lutz
wants to and not for all things.
But Paradox and the BDE are certainly not toys that should only be used for
hobbies. Just look at the ability to make fast, secure dynamic data driven
web sites completely with paradox and the web server OCX that comes with it.
Blows away asp with SQL server or access and cold fusion and it is cheap.
Plus you can easily integrate web and LAN access to Pdox systems (whatever
the back end).
Denn Santoro
President
Resource Development Associates
http://www.RDAWorldWide.Com
375 High Street
Rochester, MA 02770
(508) 295-7350
and
Waldweg 5
83512 Reitmehring
Germany
08071 924271
Providing solutions to health care, business, governments and non-profits
since 1982
David R. Robinson
aps out
> there on the BDE and Paradox. Lots of custom ones too.
We've been using Paradox tables with our commercial product since 1995.
Our product supports Paradox, InterBase, Oracle, MS SQL Server, Informix
and Sybase. Massive Paradox table and index corruption is THE reason we
became InterBase VARs in 1997.
Even with forking the code to optimize it for Paradox (which we did for
a number of years), I still stand by my statement. IMHO, when using
Paradox it is not a matter of will you get corruption, it's when will
you get corruption. The same thing also applies for any flat-file
database (i.e. Access, dBase, etc.) where the client is manipulating the
data and indices.
David R.
Dennis Santoro
I simply can't agree that corruption is inevitable. I have systems that have
NEVER had corruption (data sets still building with over 10 years of
cumulative data, hundreds of thousands of records) All corruption we have
experienced on datasets that have experienced corruption were, as I said,
traced to user error or hardware.
Sure you can't use it for everything. And maybe your system, like Lutz's,
exceeded what it can do. There are lots of ways to bring the BDE to it's
knees. But there are lots of things you can do with it as well. And lots of
commercial aps that DO run on it. File based databases do have uses. Mostly
in small to medium size settings with lower transaction and higher analytic
activity. But as I said to Lutz, just because it is not the right tool for
your job doesn't make it the wrong tool for anything. As I said to Lutz in
the thread back in the Corel paradox 9 NG version of this thread:
"Commercial aps CAN be created and run quite successfully with the BDE.
Heck, Windows crashes are a bigger cause of corruption in paradox tables
than your circumstance. Why aren't you saying "don't deliver commercial aps
in Windows, and Microsoft should be forced by the court to fix it."? If your
application exceeds
the capabilities of Paradox tables and the BDE, use a more robust C/S back
end.
Interbase is free. Other options exist. You are trying to complain that you
could not haul your herd of elephants in your half ton pickup truck so no
one should buy pickup trucks and no one should be allowed to sell them. But
they haul the stuff I need to move just fine."
The issue really is that as a developer YOU have to find and use the right
tool. It is not the job of every company that delivers a database engine to
make is scalable from the desktop to the worldwide enterprise and be
bulletproof all the way no matter what you do with it. And just because YOUR
aps exceed the limit of the BDE does not mean all, or even most, will and
that no developer should use it. No database is good for every application.
And there are a lot of factors including your normalization, user base,
transaction rate, indices, computing infrastructure, development
capabilities, budget, fixed and ongoing costs, systems with which it must
inter operate and many others which are important in picking the right
tools.
The BDE is good for a wide range of things. Paradox data format is good for
a wide range of things. Interbase data format is good for a wide range of
things, etc. And there is overlap among options. Blanket prohibitions only
make sense, at best, if no one can actually do any useful work with a
product. Certainly not in this case where there are a HUGE number of systems
out there running satisfactorily on it all the time and new ones being
successfully developed every day.
Denn Santoro
President
Resource Development Associates
http://www.RDAWorldWide.Com
375 High Street
Rochester, MA 02770
(508) 295-7350
and
Waldweg 5
83512 Reitmehring
Germany
08071 924271
Providing solutions to health care, business, governments and non-profits
since 1982
Anders E. Andersen
"Gunnar Harğarson" <gun...@isholf.is> skrev i en meddelelse
news:3b817a06_1@dnews...
> The error is not only in the Database desktop. If you try the code from
Lutz
Have you tried testing it in a grid before you use it with Database Desktop?
Anders
Gunnar Harğarson
I ran the testcode from Lutz. Made a Delphi program using dbgrid and table
components. Browse to the end and there comes the error.
This is not a serious problem for me, the reason for my original entry in
this thread is that all the entries after Lutz started seamed to deny his
problem so I decided to test his code on my side and I got the same error in
seceral different my test environments.
I dont think that will participate more in this thread, dont have time, need
to work.
Regards,
Gunnar.
Anders E. Andersen <and...@strato.dk> wrote in message
news:3b8369f5_2@dnews...
David R. Robinson
that have
> NEVER had corruption (data sets still building with over 10 years of
Congratulations! That's quite rare.
I'm not trying to get into a debate about this. I'm just saying that in
my experience with using Paradox tables for several years, it is way too
easy to corrupt the data and indices.
David R.
Dennis Santoro
with well designed normalization and single field integer indices. It
becomes less rare in unstable networks and/or with tables designed with
large alpha field keys and/or large concatenated keys.
Denn Santoro
President
Resource Development Associates
http://www.RDAWorldWide.Com
375 High Street
Rochester, MA 02770
(508) 295-7350
and
Waldweg 5
83512 Reitmehring
Germany
08071 924271
Providing solutions to health care, business, governments and non-profits
since 1982
David R. Robinson
stable net
> with well designed normalization and single field integer indices. It
> becomes less rare in unstable networks and/or with tables designed
with
> large alpha field keys and/or large concatenated keys.
Too bad that isn't heavily published. Probably would have saved 100,000
people nightmares. :)
David R.
Dennis Santoro
might find helpful. Link in my signature. Paper is a free download.
Denn Santoro
President
Resource Development Associates
http://www.RDAWorldWide.Com
375 High Street
Rochester, MA 02770
(508) 295-7350
and
Waldweg 5
83512 Reitmehring
Germany
08071 924271
Providing solutions to health care, business, governments and non-profits
since 1982
bcb
I have a few paradox tables with 200,000 records w/no indexes, using win98se
,paradox7 and C++Builder4 with 128mb ram. In user testing the computer was
shutdown(right in the middle when these tables where active) and average of
3 times per day, this was tested on 8 computers and no corruption, in my 3
years of using paradox I would say its the most stable system you can use on
a standalone computer. or on a network with a few users. Paradox is not the
best if you plan to have 20users networked Tables, this is vey important.If
you follow those rules corruption will be very rare(things happen and Tables
do sometime do get corrupted).
I didnt check with tables with indexes but testing will be going on soon.So
I cant comment on Tables with indexes. 99% of table corruptions are
indexes.Also Ive heard of issues about autoincrement fields corruption , it
tough to fix that kind of corruption.
Lutz Weder <wede...@t-online.de> wrote in message
news:3B7B7C80...@t-online.de...
> To all developers who use the BDE with Paradox:
>
> We tested BDE 5.2 with our well known example to create a corrupt file
> (" .. other than header ..."): It's the same result, the BDE 5.2
> produces a corrupt index file although we did report this bug in 2000!
>
Dennis Santoro
a single server in a multistate WAN (t1 and t3 lines and 10bt ether net) with
over 40 tables and over 200 MB data with indices without any problems other than
an occasional problem from a line dropout.
And the autoincrement issues are easily avoided. If you use paradox, we have a
commercial product (AutoKey) which is cheap and easy to implement (available on
our web site, link in my signature) and the documentation (free download) will
give you sufficient info to implement the same basic solution in other systems.
Denn Santoro
President
Resource Development Associates
http://www.RDAWorldWide.Com
375 High Street
Rochester, MA 02770
(508) 295-7350
and
Waldweg 5
83512 Reitmehring
Germany
08071 924271
Providing solutions to health care, business, governments and non-profits since
1982
Lutz Weder
That a database management system like the BDE can produce corrupt index files
during normal operations within the official published table limits and with
NO user or power shutdown even on a standalone machine is the worst case for
it. It should be normally a shipstopper!
It may be that a integer primary key allows you to create much larger tables.
But nowbody will know if it crashes again (within the limits!). Should the
programmers test every table if the BDE will handle it or not before they ship
it to the customers? The programmers MUST can be sure that the official
published limits are right!!!
If they real had similar problems with Paradox file format, why can't you
believe that? The Delphi and C++ programmers can switch to another database
(CodeBase, Advantage and so on). You CAN'T do so because you use Corel
Paradox and that is your problem! You MUST defend Paradox file format because
your applications depend on it.
The discussion about that bug we started over one year ago. Of course we
tested ALL tips from you and other programmers. Of course we tested a table
with a LongInt primary key and did put all the compound alphakeys to secondary
keys.
We changed blocksize to 32kB and level 7. It was ALWAYS possible to create a
table with corrupt secondary index files and ALWAYS within the published
Paradox limits.
Perhaps you don't know that the secondary index files are ordinary Paradox
tables with a primary key (which store the index informations). You can rename
the secondary index files to *.db and *.px files. Then you can open it like a
"normal" Paradox table. Therefore the SECONDARY indexes are PRIMARY indexes
again and there will be the same problem with compound indexes. We can give
you examples to prove that fact.
Sorry, but we will stay at our point of view: The Paradox file format is not
right for commercial programming with large databases!
Greetings from Germany
Lutz Weder
Pierre le Riche
Delphi 1 and are still using it in some of our installations.
All our clients that are still using Paradox (we have switched to MS-SQL on
out latest version) have their machines on interruptible power supplies and
various other safety measures, but we still experience data corruptions from
time to time - usually with the larger installations.
For Dennis I have a question: Have you ever had 10+ active users
continuously changing and adding records to a Paradox database? That's a
surefire way to get corruptions in no time flat.
Regards,
Pierre le Riche
"Lutz Weder" <wede...@t-online.de> wrote in message
news:3B860478...@t-online.de...
Anders E. Andersen
news:3b8393e0_2@dnews...
> Yes as I already have said I tested it in Dbgrid in Delphi.
Was that before or after you ran it through Database Desktop?
In our experiments we cannot reproduce the error using regular tables and
grids. This is not to say that the index has not been damaged, but that any
damage is not immidiately noticable (which is not really that comforting
either).
In any case we (as a company) must say that we in general have trouble with
stability using paradox tables with the BDE. Especially on large tables or
when many users are manipulating the database simultaneusly. Refreshing the
tables and flushing buffers on a regular basis, will do some to keep you out
of harms way, but we stress the importance of regular backups of the
database to all our clients.
Regards
Gunnar Harğarson
did after creating the table.
Regards,
Gunnar.
Anders E. Andersen <and...@strato.dk> wrote in message
news:3b864bed_2@dnews...
Milan Babuskov
It seems that only corruption problem are indexes.
Has anyone seen any performance boost with indexes?
I don't use indexes on my tables, and it works as fast as without it, and I
get no corruption (yet).
Please, read discusion: "Are indexes no use, or am I doing something wrong?"
from 22.08.
--
Greetings / Pozdrav,
===== ___ = Milan Babuskov, Support Engineer
==== / / / __ ___ _/_ == EUnet - YUnet International
=== /--- / / / / /__ / === Strosmajerova 24, 24000 Subotica, YU
== /___ /__/ / / /__ / ==== phone: +381 24 556 272
== === http://www.EUnet.yu/
== Connecting Europe since 1982 == e-mail: mil...@Yugoslavia.EU.net
David R. Robinson
> continuously changing and adding records to a Paradox database? That's
a
> surefire way to get corruptions in no time flat.
Good question. I'd like to see Dennis' response too.
Our experience is that if you have a lot of database updates with more
than a handful of users, you will easily get corruption.
You'll find this funny. We had a customer with over 130 users on
Paradox tables. They had been using it for a few months without any
problems. They probably had 75+ concurrent users. When we found on
that they were using Paradox (because it was free compared to a decent
client/server database engine) we begged and pleaded with them to get
off of Paradox. They refused stating that it was working fine. All of
the sudden, once the main data file grew to a certain size, the DAT file
was truncated to 128 bytes. They lost every single data record and had
to restore from backup. After this happened three or four times within
a week, they finally took our advice and switched off of Paradox.
Obviously this is an extreme case since as you would think that any MIS
or IT manager with common sense would not put 130 users on a Paradox
system. However, we have seen situations exactly like I described with
15 user installations as well.
David R.
Dennis Santoro
I have had over 100 users doing so in a mixed LAN/WAN environment in a system
with over 40 tables and hundreds of megs of data. No issues. But generally the
systems I design are somewhat smaller. Small to midsize companies, low
transaction, high analysis demands. Things like patient tracking systems in
clinics, fundraising/contact management in human services organizations,
contract management systems at HMOs, etc. POS and inventory stuff for small to
medium size businesses. If I were designing in high transaction environment I
would normally look to something that is much more transaction capable
(interbase, etc.)
Denn Santoro
President
Resource Development Associates
http://www.RDAWorldWide.Com
375 High Street
Rochester, MA 02770
(508) 295-7350
and
Waldweg 5
83512 Reitmehring
Germany
08071 924271
Providing solutions to health care, business, governments and non-profits since
1982
Dennis Santoro
indices? Indices are essential in relational design (primary ones). And
secondary indices are generally needed for stable linking. Some secondary
indices do improve performance, but not all. But for most tables I would have a
primary index of a meaningless integer. In child tables I would also add a
foreign key which is the primary of the master. Then that foreign key (which is
not part of the child table's primary key) would have a secondary index on it so
the master and child can be linked. If I need to manage a M:M link I would use a
relationship table where the key is the primary key of both related tables and a
secondary index exists on the reverse. In this case I have a 2 integer field,
concatenated key. This is about the ONLY circumstance under which I use
concatenated keys. The primary index on the 2 fields and the secondary index on
the same two in reverse order allows for either side of the M:M to be master or
child.
Other than linking, I use secondary indices when I need them for setting ranges,
sorting or searching (if it will speed the search up) otherwise I don't add
them. I only create secondary indices I have a specific use for.
HTH
Denn Santoro
President
Resource Development Associates
http://www.RDAWorldWide.Com
375 High Street
Rochester, MA 02770
(508) 295-7350
and
Waldweg 5
83512 Reitmehring
Germany
08071 924271
Providing solutions to health care, business, governments and non-profits since
1982
Dennis Santoro
Please read in line...
Lutz Weder wrote:
> Dennis, please stop your teaching of other people.
Why should I stop any more than you? Should your statement go unchallenged when
they are so blatantly illogical? As I have said MANY times, just because YOU can't
use the Paradox/BDE combo with YOUR design does not mean all developers should
stop using it. It means YOU should. As I said to your codeveloper over in the
Paradox 9 thread:
"Your logic is just as flawed as Lutz's. You argue from a specific to the general
and
create a logical fallacy. (e.g. My sister is a female. My sister is a wife.
Therefore all females are wives.) It just isn't so.
You experience corruption in your design. You will not change the design. Therefor
YOU should not use Paradox/BDE for YOUR commercial ap. It does NOT follow that I
should not as I don't use your design and I don't experience corruption in my
designs."
> That a database management system like the BDE can produce corrupt index files
> during normal operations within the official published table limits and with
> NO user or power shutdown even on a standalone machine is the worst case for
> it. It should be normally a shipstopper!
That they can, and in some cases do is no more a showstopper than that Windows
can, and sometimes does, crash. I have many systems running where I do not get
corruption under normal operations. So do many others. So we should stop using a
perfectly good tool because you say so and you can create circumstances under
which you can demonstrate corruption. Be serious. We KNOW corruption is possible.
We also can design so as not to experience it. As for published limits, again,
they are THEORETICAL limits. I would never consider them practical ones nor try to
get very close to them. If I am looking at a systems that will exceed a few
hundred MB of data I would not be likely to even consider starting it in Paradox
ad a file format. I'd be looking at interbase. But there are a huge number of
systems that I and others design that will NEVER get near those sorts of sizes.
> It may be that a integer primary key allows you to create much larger tables.
> But nowbody will know if it crashes again (within the limits!). Should the
> programmers test every table if the BDE will handle it or not before they ship
> it to the customers? The programmers MUST can be sure that the official
> published limits are right!!!
The published limits are right; theoretically. That is different from practically.
Sure you can design systems that will crash paradox of the BDE. Sure you can make
it happen way below the theoretical limits. So what? You can also create a lot of
aps that this will never be an issue for. Yes the programmer must be sure their ap
will work. And that the published limits are correct. But the programmer must also
realize that theoretical limits are theoretical limits. Theoretically I can travel
the speed of light. Practically, I know no way of doing so. So I am not going to
try and drive my car the speed of light.
> If they real had similar problems with Paradox file format, why can't you
> believe that?
I do. So what? Occasionally a plane crashes because of pilot error. That does not
stop me from flying on any plane that has a pilot.
> The Delphi and C++ programmers can switch to another database
> (CodeBase, Advantage and so on). You CAN'T do so because you use Corel
> Paradox and that is your problem! You MUST defend Paradox file format because
> your applications depend on it.
That is just plain silly. I can use interbase, mySQL, Sybase, etc. as back ends t
paradox any time I want. And I am NOT defending the BDE. I am saying your position
is ridiculous. Let me try this again:
My position: Depending on your database design, the BDE may, or may not be the
right tool for the job. If it is the right tool, great. Use it. If it isn't don'
use it.
Your position: In my database design I get corruption in the database using BDE.
Therefore I can't use the BDE and if I can't no one else should either.
Get real.
> The discussion about that bug we started over one year ago. Of course we
> tested ALL tips from you and other programmers. Of course we tested a table
> with a LongInt primary key and did put all the compound alphakeys to secondary
> keys.
> We changed blocksize to 32kB and level 7. It was ALWAYS possible to create a
> table with corrupt secondary index files and ALWAYS within the published
> Paradox limits.
OK. So your design may not be possible to create in the BDE under any
circumstances. It may also be an issue of normalization but we don't know for
sure. It doesn't matter. You say you can't use it because of corruption. Fine. I
believe you. I say I have systems that are very large, have many users, run on
lans/wans and the internet and do not experience corruption. So why should your
problem cause me to stop using a system I know to be a perfectly good tool for my
purposes? Please try and give me even one reason for that.
> Perhaps you don't know that the secondary index files are ordinary Paradox
> tables with a primary key (which store the index informations). You can rename
> the secondary index files to *.db and *.px files. Then you can open it like a
> "normal" Paradox table. Therefore the SECONDARY indexes are PRIMARY indexes
> again and there will be the same problem with compound indexes. We can give
> you examples to prove that fact.
As a matter of fact I do know that. Again, so what? It just means you have to
think about your secondary index design as well. And that secondary indices fall
under the same PRACTICAL limits as tables do.
> Sorry, but we will stay at our point of view: The Paradox file format is not
> right for commercial programming with large databases!
I am not trying to change YOUR point of view. I am trying not to leave your
assertions unchallenged so that others will think about using the right tool for
the job. If you need a larger scale database engine, of course you should use one.
If the BDE will do the job, use that. Why is it so hard for you to accept that
other people are quite capable of designing and implementing stable systems in the
BDE which they can sell commercially and run whole businesses on?
Dennis Santoro
And for the folks who may be missing it, there is a difference between the
Paradox file format and Paradox, the IDE. Paradox (IDE) can be used against
the paradox file format or other file or C/S back ends.
Denn Santoro
President
Resource Development Associates
http://www.RDAWorldWide.Com
375 High Street
Rochester, MA 02770
(508) 295-7350
and
Waldweg 5
83512 Reitmehring
Germany
08071 924271
Providing solutions to health care, business, governments and non-profits
since 1982
Danny Brown
"Dennis Santoro" <RDA...@RDAWorldWide.com> wrote in message
news:3B866F29...@RDAWorldWide.com...
> How are you managing linking and keeping records unique if you don't use
> indices? Indices are essential in relational design (primary ones). And
Am I less likely to see corruption problems if 90% of my data manipulation
is done with querys? I am only using TTable etc.. for adding records (using
a database grid) not viewing. Of course, I assume if I close down my TTable
whenever its not in use ,for instance when my form for adding records does
not have focus , will this also help eliminate problems? Or, will closing
and opening the table often create corruption? I would love to see some
discussion which might lead to some guidlines to help prevent this problem.
Any Ideas?
David R. Robinson
D'oh! I meant DB (data) file.
David R.
Dennis Santoro
Sorry, but I don't personally program in Delphi. I dabble a bit but not enough
to answer this question.
Denn Santoro
President
Resource Development Associates
http://www.RDAWorldWide.Com
375 High Street
Rochester, MA 02770
(508) 295-7350
and
Waldweg 5
83512 Reitmehring
Germany
08071 924271
Providing solutions to health care, business, governments and non-profits since
1982
Milan Babuskov
I don't need a relational-theory class, thank you.
When I use Paradox with BDE, I maintain referential integrity in code, and
link tables with JOIN statement or WHERE clause, depending on the needs. I
made special lookup components and never allow user to enter foreign key
value, but rather pick one from list. I have never had any referential
integrity problems that way.
I also made my own version of TUpdateSQL component (I use BCB) which can
have multiple sql statemets for each of Insert/Update/Delete actions, and it
works like triggers. Of course, I didn't write all those trigger-statements.
I use ER-Win templates to do the job for me.
I haven't seen any performance decrease when dropping indexes from ALL of my
tables.
--
Greetings / Pozdrav,
===== ___ = Milan Babuskov, Support Engineer
==== / / / __ ___ _/_ == EUnet - YUnet International
=== /--- / / / / /__ / === Strosmajerova 24, 24000 Subotica, YU
== /___ /__/ / / /__ / ==== phone: +381 24 556 272
== === http://www.EUnet.yu/
== Connecting Europe since 1982 == e-mail: mil...@Yugoslavia.EU.net
Dennis Santoro <RDA...@RDAWorldWide.com> wrote in message
news:3B866F29...@RDAWorldWide.com...
Lucian
altered. A had tried to repair it with a utility, but I lost some records.
Another problem: I append and post some records from a file to another file
(both paradox) then after more appends appears "Incorect parameter". Local
share was "TRUE". If switch to 'FALSE' works fine.
My ask is: How works Interbase with BDE? If a database will crash can I
repair it? Did someone test Interbase with Zeos components?
The problems are only with Paradox tables? If I'll use Dbase tables (or
another) with BDE?
Thanks.
Lucian Rosca
bcb
That even more proves that paradox isnt that bad : )
For everyone else with questions try looking here for answers:
corel.wpoffice.paradox-FAQ ->newsgroup
Bye. : )
Dennis Santoro <RDA...@RDAWorldWide.com> wrote in message
news:3B85EE73...@RDAWorldWide.com...
Leslie Milburn
I was just wondering if the Table language has been looked at. I
remember reading a book years ago by Ehrmann that said depending upon
the table language, an additional translation process is undergone.
Just an idea.
Danny Brown <dbr...@trentech.com> wrote in message
news:3b8674d8_1@dnews...
> ...... I would love to see some discussion which might lead to some
d
commercial apps. but have they?
first the major problem is not bde but paradox because if you use sqlsrver
as a database it is limited but works ok.
when I fist looked at paradox I found it to be feature rich, then I started
to deploy it. I don't use no name equipment and there are virtually no other
db apps having a problem with the network only paradox apps. the worst app
that I built was only 200 recs in size max, and 40 users, very small db but
accessing it was very high. it was a special phone message program. when the
updates were set to 2 sec's (they need to know who's on the phone) it would
crash in less than 5 min. then I set it to 1 min and it would crash in 1-2
hrs. then I reprogrammed it so every system took turns a accessing the
paradox database one at a time. problem solved. it now has run for 3 years
without a single error.
the problem with paradox is the file sharing system it uses (most local db's
have this problem but paradox is the worst) when a addional users access the
db they write to the actual file if another user also writes to the file and
indexing files this is where the problem is. FoxPro uses a recovery approach
that is why if I have to use a local db I use that one. It is 100x better
than paradox. but now to eliminate data loss I have been using MSDE (free
sql server) and full sqlserver 7.0 & 2000 for almost 2 years of using it I
have not had a single crash (I wonder why I bother with backups)
dave rolleman
drol...@home.com
Tomi
years with no problem (maybe one index crash per month). Some tables are
more then 200.000 records long and they have from 1 to 6 secondary indexes.
There are five users and eight standalone program modules using dbase
concurrently. Refresh on 2-5 seconds.
Tomi