Hello,

Does anyone know if it is possible to create referential integrity for Paradox tables in SQL? I cannot find it in theh local SQL help. What's the use of being able to create tables in SQL if you can't define constraints? I want to be able to generate my database through SQL scripts.

Thanx in advance,

Neeva

Local SQL does not support creating constraints
(either referential integrity, or Default,Min,Max values for the field).
You have to resort to dbiDoRestructure.
Please keep in mind that Paradox is not SQL database,
so you can't expect that much from SQL.
--
Roman
(please remove 'stopspam' in header when replying)
mail: i...@rksolution.cz
URL: www.rksolution.cz

neeva <maarten.vl...@no-spam.wanadoo.nl> p1e v diskusnm
p?spvku:39dd9a97$1_1@dnews...

Paradox tables in SQL? I cannot find it in theh local SQL help. What's the
use of being able to create tables in SQL if you can't define constraints? I
want to be able to generate my database through SQL scripts.

You cannot do it in SQL. I beleave there is an example using the BDE API
call DbiDoRestructure at www.borland.com/devsupport/bde/bdeapiex .

--
Bill Todd (TeamB)
(Questions received via email cannot be answered.)

Hi Roman!

Since those constraints are already supported by paradox file format
it doesn't make any sense that programmers who wrote local SQL didn't
take that into the syntax.

tomi.

news:39e1af70.4167228@forums.inprise.com...

Since paradox only partially implements referential integrity ( no cascade
deletes )
and since we had database integrity problems with large databases when using
referential integrity we choose not to use it. We have very good success
with
multiple users and large databases.

Garry Kernan

Hi Garry,

So you create code to ensure database integrity?

Neeva

Yes

It really does not amount to alot of work for our application.

Some of our data relationships are effectively object oriented and do not
fall under standard relational set theory.

Garry Kernan

news:39e2e961$1_2@dnews...

Hi Tomi,

Since local SQL works with desktop databases in general,
and Ref.Int is a Paradox specialty, it does, IMHO, make sense :-)

Roman

Hi Sympatico!

On Mon, 9 Oct 2000 11:04:17 -0600, "Sympatico"

Whell, MS SQL Server 6.5 also doesn't support cascade deletes, this
fact don't prove anything, it's just a feature you might or not want
to happen.

Referential integrity is exatly meant to cause you problems when you
don't obey rules you made yourself when creating database. Suppose you
have a master and detail tables, so if you don't put a foreign key
constraint for detail table on master key it can happen that you have
detail records without the master one. This may cause you less trouble
in a bad design, but certainly is not a way to go.

I am sure you have.

tomi.

Hi Roman!

On Wed, 11 Oct 2000 11:55:09 +0200, "Roman Krejci"

If it makes sense to write an SQL engine for paradox tables with which
you can create tables, then there is a lot of sense to complete the
work properly and not let it be unfinished.

That's my point with or without sense od making Local SQL in the first
place, that's not the issue here. The issue is that the product is not
finished, and that makes no sense.

tomi.

You simply point out that MS SQL server also implements only partial
referential integrity.
Typical Microsoft. (and yes I do know about the Microsoft / Sybase history)

Because I do not with to use pardoxes referential integrity does not suggest
a bad
design nor that we do not know how referential integrity works both from
relational set theory and practical use.
Do realize that dbGrids and master detail relationships automatically supply
proper foreign key values when appending records at the GUI level.

We also choose NOT to edit PK values as that practice with paradox can
result in higher risk of data corruption.

Paradox uses a paging scheme and stores the PK value of the first record
of each page as an entry in the *.px table. This forces the BDE to keep
data in primary key order. Editing PK values causes page splits and
reordering of page data. This effectively causes ALL secondary indexes
to be looked at an potentially modified.

For us this this is simply one of the dozen or so rules we have tacked
on top of paradox to help paradox to avoid data corruption, index out of
date, header corruption etc.

We collect large amounts of data in vehicles and then batch process this
data
while the driver is standing in front of an ATM style machine. We choose
paradox because it can process 10,000 records per second using block writes.
We removed referential integrity to obtain these levels of throughput.

Many c/s people are content with 200 records per second - this simply does
not work for us.

Our core databases are composed of around 20 tables and are all related (at
some level)
The data model has morphed into an object oriented data collection system
that
does not fully fit within relational set theory.