Help with Paradox 9 table schema
dwightarmy...@hotmail.com
database tables. I work with Paradox 9 through Borland C++ Builder
2006. I want to have two database tables, one called Transactions and
another called TransactionDetails. Transactions has primary key
TransactionID, which is an ftString. TransactionDetails has a primary
key (TransactionID, TransactionAccountType) and both are strings.
Now, I want to make TransactionDetails be a child of Transactions so
that:
1. I cannot add a record to Transactions without first adding it to
TransactionDetails.
2. When I update a record in the Transactions table, the corresponding
record in TransactionDetails (i.e. the records with the same
TransactionID number) will also be updated. For example, if I go into
Transactions and change a record's TransactionID number from 1111 to
2222, it will automatically search in TransactionDetails for all
records that have a TransactionID number of 1111 and change those to
2222 automatically.
How do I form these two tables?
As it is now, I have C++ code that creates the two tables:
////////// CODE BEGINS HERE //////////
// create parent table
TTable* taTransactions = new TTable(this);
taTransactions->DatabaseName = "C:\\temp";
taTransactions->TableType = ttParadox;
taTransactions->TableName = "Transactions.db";
taTransactions->FieldDefs->Clear();
taTransactions->FieldDefs->Add("TransactionID", ftString, 10, true);
taTransactions->FieldDefs->Add("TransactionDate", ftDateTime, 0,
true);
taTransactions->FieldDefs->Add("TotalAmount", ftCurrency, 0, true);
taTransactions->IndexDefs->Clear();
taTransactions->IndexDefs->Add("", "TransactionID",
TIndexOptions()<<ixPrimary);
// create child table
TTable* taTransactionDetails = new TTable(this);
taTransactionDetails->DatabaseName = "C:\\temp";
taTransactionDetails->TableType = ttParadox;
taTransactionDetails->TableName = "TransactionDetails.db";
taTransactionDetails->FieldDefs->Clear();
taTransactionDetails->FieldDefs->Add("TransactionID", ftString, 10,
true);
taTransactionDetails->FieldDefs->Add("TransactionAccountType",
ftString, 5, true);
taTransactionDetails->FieldDefs->Add("TransactionType", ftString, 5,
true);
taTransactionDetails->FieldDefs->Add("AmountReceived", ftCurrency, 0,
true);
taTransactionDetails->FieldDefs->Add("AmountDisbursed", ftCurrency, 0,
true);
taTransactionDetails->FieldDefs->Add("AccountNumber", ftString, 8,
true);
taTransactionDetails->FieldDefs->Add("PersonID", ftString, 10, true);
taTransactionDetails->FieldDefs->Add("Percent", ftFloat, 0, true);
taTransactionDetails->IndexDefs->Clear();
taTransactionDetails->IndexDefs->Add("",
"TransactionID;TransactionAccountType", TIndexOptions()<<ixPrimary);
taTransactions->CreateTable();
taTransactionDetails->CreateTable();
// delete pointers
delete taTransactions; taTransactions = 0;
delete taTransactionDetails; taTransactionDetails = 0;
////////// CODE ENDS HERE //////////
Problem is I don't quite have it yet. There's no "link" between
Transactions and TransactionDetails. I know there's a much MUCH easier
way to do this via the Paradox 9 program instead of C++.
Unfortunately, I don't really know how to use that. Can anybody help
me?
Tony McGuire
This appears to be a C++ question, rather than a Paradox question.
Althogh you mention 'Paradox 9' (?).
While someone may be able to help you here, you may be better served
asking this on a C++ forum.
> way to do this via the Paradox 9 program instead of C++.
> Unfortunately, I don't really know how to use that. Can anybody help
> me?
Well, getting a C++ answer will be a LOT easier than starting from
scratch with Paradox the Application.
--
------------------------------
Tony McGuire
Steven Green
it's the platform you use.. always ask questions to the people using your
native platform..
however, your game-plan has flaws, no matter what platform:
> so that I cannot add a record to Transactions without first adding it to
> TransactionDetails.
that's backwards, but I think this was a typo.. if not, it's definitely
problematic.. you *always* create the master first..
> 2. When I update a record in the Transactions table, the corresponding
> record in TransactionDetails (i.e. the records with the same TransactionID
> number) will also be updated.
serious design flaw here.. the primary key should never change.. its either
a sequential value, or a system-generated value.. it's not user-defined,
and should *never* change..
--
Steven Green - Myrtle Beach, South Carolina USA
Diamond Software Group
http://www.diamondsg.com/main.htm
Paradox Support & Sales
Diamond Sports Gems
http://www.diamondsg.com/gemsmain.htm
Sports Memorabilia and Trading Cards
Robert Molyneux
>> 2. When I update a record in the Transactions table, the corresponding
>> record in TransactionDetails (i.e. the records with the same TransactionID
>> number) will also be updated.
>
> serious design flaw here.. the primary key should never change.. its either
> a sequential value, or a system-generated value.. it's not user-defined,
> and should *never* change..
>
So the concept of "referential integrity" means what exactly?
Answer: in the event that someone wants to change the primary key in a
master table, the RDBMS automatically changes the key(s) in the detail
table(s) to retain "referential integrity".
And while some people think that the primary key should not contain
meaningful data, making it meaningless is really just a convention,
partly to make it easy for RDBMS developers.
To assign meaning to keys requires some human intervention - sometimes
easier to use a sequential number, especially when lots of records are
involved.
BTW: Why do you and Tony always jump on newcomers and tell them to go
elsewhere, rather than address their issues or just staying silent?
The answer to this guy's question is for him to buy a copy of Paradox
for a few dollars, spend a few minutes reading up on how it handles
table creation and relationship, and let him get on with it.
If he wants to explain how he does things in C++ or Delphi or Esperanto,
and we can show him how to do it in a very good RDBMS for 1/4 the time
(that's why it's called a 4GL, BTW), don't we all benefit?
Steven Green
> elsewhere, rather than address their issues or just staying silent?
it's not "jumping on newcomers".. it's telling developers in other platforms
to go to *their* platform for the best ongoing help in *their* platform,
when they're posting code samples that must be analyzed.. if you don't do
that, even if you *can* offer a little bit of advice, you're not doing your
job to the best of your ability..
and, since you asked:
> So the concept of "referential integrity" means what exactly?
it doesn't mean that changing the primary key is generically intelligent,
even if the software will sometimes handle it for you..
> To assign meaning to keys requires some human intervention
and, in most cases, leaves you wide open to forced changes, when something
within the meaning of the key of that record changes.. the woman gets
married, the corporation gets bought out by another corporation, part
numbers need to be padded with an extra leading zero, archived data rolls
over to a new century, etc..
for the inexperienced developer, *that* is when they learn the important
lessons like this.. much better to preach generic simplicity, than to have
to explain the potential nuances to somebody that doesn't understand it
yet..
in every instance, you're not just replying to the OP.. your message is
being read by many, many other people, too.. the "lurkers" who never say a
word and/or present themselves in e-mail sometime after the original thread
passes Jupiter..
--
Steven Green - Myrtle Beach, South Carolina USA
Diamond Software Group
http://www.diamondsg.com/main.htm
Paradox Support & Sales
Diamond Sports Gems
http://www.diamondsg.com/gemsmain.htm
Sports Memorabilia and Trading Cards
"Robert Molyneux" <ibisnestre...@iinet.net.au> wrote in message
news:48a9...@pnews.thedbcommunity.com...
Larry DiGiovanni
> I'm a total newbie to Paradox and I need some help creating my
> database tables.
Why are you using Paradox tables with BC++?
The code you've shown creates the tables. Even if you figure out how to add
the Referential Integrity as part of this code, or with Paradox, you won't
get the cascading update you're looking for. I think that is the simple
answer to your question.
The only way to get this sort of behavior against Paradox tables is to
include this logic in your application behavior -- which also means you
cannot rely on it.
So my question about why Paradox is based on two facts:
(1) There are other RDBMSs that do support cascading RI -- why not use one
of them instead?
(2) The BDE and the Paradox table format are deprecated
--
Larry DiGiovanni
Larry DiGiovanni
> it's not "jumping on newcomers".. it's telling developers in other
> platforms to go to *their* platform for the best ongoing
> help in *their* platform,
You can't always know they haven't done both, though. In this case, it
appears that his root problem is specific to the Paradox table architecture,
and IMHO, he did come to the right place.
> and, in most cases, leaves you wide open to forced changes, when
> something within the meaning of the key of that record changes..
Only when using an RDBMS that doesn't support RI very well, something he
know knows as a result of posting his question here.
--
Larry DiGiovanni
Jim Hargan
wrote:
>. There's no "link" between
> Transactions and TransactionDetails. I know there's a much MUCH easier
> way to do this via the Paradox 9 program instead of C++.
> Unfortunately, I don't really know how to use that.
What Larry said. Plus, I though I'd actually answer your question! ;-}
Yes, there is a much easier way to do this in PDox9. If you create your app
wholly within Pdox9, and abandon C++ altogether, creating tables with RI is
trivial -- but comes with *BIG* potential problems.
First, here's how you do it. Create the two tables using File/New/Tables --
the dialog is self-explanatory. Be sure to create the primary index by
putting the index fields first and putting an asterisk in front of them
(this will be clear when you see the dialog). NOW, re-open this dialog for
the subtable -- you do this with Tools/Utilities/Restructure. The far right
tab is "Referential Integrity". Use this to link it to the parent table.
That's it!
Now for the problems. Paradox is the Tounces of the RI world. It does it --
just not very well. The big problem is that the table directory paths are
HARD CODED into the structure, right down to the drive letter. If you move
either table, your whole application breaks. This makes Paradox RI
effectively undeliverable. For a one-person standalone application it does
what you want -- until you decide to buy a new computer. Then you have to
EXACTLY duplicate the drive and directory structure on the new machine. And
don'd even THINK about rearranging your hard drive.
Most of us just do RI in code, which is pretty easy once you are used to
Paradox's powerful language, OPAL, specifically structured for a RAD
database environment.
And that's the second problem: OPAL is a very odd language, and C++ by
itself will only help you a little. OPAL uses pointers a lot, much like
C++; but it is designed to look like Pascal; and it is event-driven, like
JavaScript in a browser. You cannot create new classes or objects
programmatically. Instead, you define all your objects interactively, then
hang code onto them ONLY as it is needed to modify their default behavior.
The trick is to learn the default behavior (which is VERY subtle and
complex) and only then learn what code you need to change this.
The reward: once you internalize this, Paradox is the ultimate RAD (except
for the RI problem of course). But, as both OPAL and the BDE have been
deprecated, is it worth your while? Did I mention that Paradox does not
have a Vista-ready version?
If your choice is learning Paradox from scratch vs Access or Foxpro,
Paradox is, IMHO, the better choice -- simpler and more powerful despite
its problems. But that's not your choice, is it?
--
HTH
Jim Hargan
Tony McGuire
> BTW: Why do you and Tony always jump on newcomers and tell them to
> go
> elsewhere, rather than address their issues or just staying silent?
'While you might get an answer here, you might be better served...'
If you had run into as many threads as I have with 20 answers for
Paradox when the question was for Delphi based on Paradox tables, and
no one realized it, you MIGHT just do the person, and those answering,
the favor of distinguishing between Paradox and Paradox tables as
well.
I'm not 'jumping on' them. Merely trying to help distinguish whether
they are wasting their time here when they could be asking their
question of experts in the language they are asking about.
I don't stay silent any longer because it doesn't help them.
------------------------------
Tony McGuire
Steven Green
true.. however, if he has gone to the Borland Builder forums, they'll shoot
down "using paradox tables" much more directly than we do.. over there,
everyone says "don't do it".. there is no mixed audience, as there is here..
> In this case, it appears that his root problem is specific to the Paradox
> table architecture, and IMHO, he did come to the right place.
also true, perhaps.. but you've done a good job of shooting down his basis,
and Jim has done a good job of showing the complexity of attempting it in
Paradox instead of Builder..
in any case, when they start by posting a bunch of code for another
platform, we *do* need to point out that the other platform's forum is the
place to assess the validity of that platform's code and concepts, even if
paradox tables are involved..
Robert Molyneux
>
> Now for the problems. Paradox is the Tounces of the RI world. It does it --
> just not very well. The big problem is that the table directory paths are
> HARD CODED into the structure, right down to the drive letter. If you move
> either table, your whole application breaks. This makes Paradox RI
> effectively undeliverable. For a one-person standalone application it does
> what you want -- until you decide to buy a new computer. Then you have to
> EXACTLY duplicate the drive and directory structure on the new machine. And
> don'd even THINK about rearranging your hard drive.
>
Just for the record, this is not true.
All tables that have RI relationships must be in the same directory, and
the path is irrelevant.
However, lookup tables can potentially span directories - you could have
a directory for handy lookup tables, used by one or more applications,
with the main tables located in other directories.
Then, you can use Paradox's excellent aliases (hugely useful concept) to
link tables to :MyLookups:LookupOfPostCodes and so on.
Trouble is, when you relocate the tables, and redefine the aliases, you
discover that the aliases have been converted into hard-coded paths, and
nothing works anymore - a bit like M$ Work when it breaks all linkages
to sub-documents and other objects if you move a document.
So you can use RI and lookups very easily, but all files related like
this must be in the same directory.
In my case, I have lots of directories for different "sub-databases",
and I replicate some lookup tables that are required to be used within
multiple sub-databases. A minor administrative annoyance.
This is not to say that RI actually works very well. Lookups do, though,
to enforce allowable sets.
BTW: Metadata about table properties and linkages are held in files
Table_Name.VAL.
If you delete or rename .VAL files, all constraints on master-detail
data actions are removed, so you can do stuff like deleting master
records before deleting detail records, or adding detail records before
adding master records. Especially useful for handling groups of tables
that have cross-linked relationships.
You can rename them, do the business, then rename them back again,
without losing metadata.
dwightarmy...@hotmail.com
> First, here's how you do it. Create the two tables using File/New/Tables --
> the dialog is self-explanatory. Be sure to create the primary index by
> putting the index fields first and putting an asterisk in front of them
> (this will be clear when you see the dialog). NOW, re-open this dialog for
> the subtable -- you do this with Tools/Utilities/Restructure. The far right
> tab is "Referential Integrity". Use this to link it to the parent table.
> That's it!
After testing this on two of my tables, this approach appears to have
worked. I can change the ID field in one table, and that automatically
updates the corresponding records in the child table. Thank you very
much. Now if I could get it working through C++ I'd really be cooking.
> Most of us just do RI in code, which is pretty easy once you are used to
> Paradox's powerful language, OPAL, specifically structured for a RAD
> database environment.
>
This OPAL language sounds interesting. Do you know if there's any way
I can integrate this into a Borland C++Builder application?:Where else
can I learn abouit OPAL? I've never even heard of it. There doesn't
even seem to be a Wikipedia article on it.
dwightarmy...@hotmail.com
> While someone may be able to help you here, you may be better served
> asking this on a C++ forum.
>
Unfortunately, the Borland C++ newsgroups are nowhere near as populous
as these Paradox newsgroups are. This question here has gotten 11
replies, and I asked pretty much the same question at
borland.public.cppbuilder.language.cpp and I haven't gotten a single
reply. :(
dwightarmy...@hotmail.com
>
> Why are you using Paradox tables with BC++?
>
I inherited an old C++ Builder application that has been using
numerous different Paradox tables for different branches of our
company for years. My job is to take these tables and move them into
two big gigantic tables (one child, one parent) in a MySQL database.
One of the necessary steps is modifying the ID numbers for both parent
and child tables to better prepare them for the MySQL migration. If I
only have to update the ID numbers in the parent table (child's ID
numbers will update through referential integrity) this will be a
significant timesaver.
> The code you've shown creates the tables. Even if you figure out how to add
> the Referential Integrity as part of this code, or with Paradox, you won't
> get the cascading update you're looking for. I think that is the simple
> answer to your question.
>
> The only way to get this sort of behavior against Paradox tables is to
> include this logic in your application behavior -- which also means you
> cannot rely on it.
>
> So my question about why Paradox is based on two facts:
>
> (1) There are other RDBMSs that do support cascading RI -- why not use one
> of them instead?
> (2) The BDE and the Paradox table format are deprecated
"deprecated"?
Steven Green
> can integrate this into a Borland C++Builder application?:Where else can I
> learn abouit OPAL? I've never even heard of it.
it's the programming language built into paradox software..
Steven Green
> these Paradox newsgroups are
might just be a timing issue.. overall, the borland groups are great.. the
paradox group evolved from borland groups, when paradox was part of
borland.. right now, all the old borland groups got axed, and the new
embarcadero groups just started as the replacement..
Steven Green
> (one child, one parent) in a MySQL database.
excellent.. so the re-naming is just a one-time thing for conversion..
dwightarmy...@hotmail.com
> might just be a timing issue.. overall, the borland groups are great.. the
> paradox group evolved from borland groups, when paradox was part of
> borland.. right now, all the old borland groups got axed, and the new
> embarcadero groups just started as the replacement..
what's "embarcadero"?
Larry DiGiovanni
> The far right tab is "Referential Integrity". Use this to link it to
> the parent table. That's it!
<sheepish grin>
I had no idea Paradox supported cascading updates through RI.
--
Larry DiGiovanni
Larry DiGiovanni
> This OPAL language sounds interesting. Do you know if there's any way
> I can integrate this into a Borland C++Builder application?:Where else
> can I learn abouit OPAL? I've never even heard of it. There doesn't
> even seem to be a Wikipedia article on it.
Check out the Programming section of www.thedbcommunity.com for lots of
articles on ObjectPAL. I'm unaware of anyone utilizing ObjectPAL outside of
Paradox or Paradox Runtime.
--
Larry DiGiovanni
Larry DiGiovanni
> This OPAL language sounds interesting. Do you know if there's any way
> I can integrate this into a Borland C++Builder application?:Where else
> can I learn abouit OPAL? I've never even heard of it. There doesn't
> even seem to be a Wikipedia article on it.
Check out the Programming section of www.thedbcommunity.com for lots of
articles on ObjectPAL. I'm unaware of anyone utilizing ObjectPAL outside of
Paradox or Paradox Runtime.
In a nutshell, ObjectPAL is sort of a non Object-Oriented version of
ObjectPascal, but with a rich set of built-in classes for manipulating any
table, field, or UI element of a form or a report.
--
Larry DiGiovanni
Tony McGuire
Deprecated means no longer used (going forward) and no longer
supported (by the company that created/owns it).
Embarcadero is the company that bought 'Borland'. All the development
tools, anyway. Not sure if they bought the name as well.
The remainder company that WAS Borland is delving into Witchcraft, or
Gaea worship .. or something.
------------------------------
Tony McGuire
Steven Green
the company that bought CodeGear, the spin-off that was Delphi, etc..
--
Steven Green - Myrtle Beach, South Carolina USA
Diamond Software Group
http://www.diamondsg.com/main.htm
Paradox Support & Sales
Diamond Sports Gems
http://www.diamondsg.com/gemsmain.htm
Sports Memorabilia and Trading Cards
<dwightarmy...@hotmail.com> wrote in message
news:909ee1d4-8c3f-4970...@s50g2000hsb.googlegroups.com...
dwightarmy...@hotmail.com
This is interesting. So does this mean that C++ Builder and Delphi are
becoming obsolete?
Tony McGuire
> This is interesting. So does this mean that C++ Builder and Delphi
> are
> becoming obsolete?
Obviously, not if Embarcadero can help it.
And there are even a couple of people who are hoping they'll do
SOMETHING that will help Paradox.
--
------------------------------
Tony McGuire
dwightarmy...@hotmail.com
> Check out the Programming section ofwww.thedbcommunity.comfor lots of
> articles on ObjectPAL. I'm unaware of anyone utilizing ObjectPAL outside of
> Paradox or Paradox Runtime.
>
> --
> Larry DiGiovanni
OK, so after playing around with ObjectPAL for about an hour, could
someone show me how to create a cascading referential integrity link
on a field TransactionID in a parent table called Transactions and a
child table called TransactionDetails? In one of those articles on
www.thedbcommunity.com called "Do It Yourself Referential Integrity",
the author declines to show a working code sample because it is
unreliable. Well, I'd still like to know how. I don't care if it's
unreliable.
Jim Hargan
self-contained child databases -- so everything I use is always aliased,
and therefore ends up hard coded.
Jim Hargan
Jim Moseley
Robert,
The main deal-breaker for me with Pdox's R.I. was if a table became corrupt.
When Tutil32 rebuilt it, it also included the backed up 'copy of' table
in the new R.I. chain.
This would cause table open errors, since obviously, the backed up table
was corrupt to begin with.
The only way I found to fix this was to delete the VAL file & rebuild it.
Jim Moseley
Robert Molyneux
> Much here that is new to me! Like you, I use a lot of sub-directories for
> self-contained child databases -- so everything I use is always aliased,
> and therefore ends up hard coded.
>
> Jim Hargan
If you change the working directory to the child database, when you do
the linkage of tables for lookups you do not need to use aliases. From
then on, Paradox simply assumes that the main table and the lookup table
are in the same directory, and does not store the pathway.
Then you can reset the working directory, and still reference the tables
using aliases, with all relationships working correctly.
If you do use aliases, you can move the database from one system to
another provided that you can map the location to the same letter on the
new system as on the old. For example, I used to have all my tables
nicely set out in directories, heavily cross-referenced with aliases,
and all saved in Q:\Database_Directory. So long as I could snaffle the
Q:\ mapping there was no problem. But of course, generally this is not
acceptable.
Some years ago I suggested in this forum that (a) aliases were a really
great concept, and (b) the way they were turned into hard-coded paths
was a really great boo-boo - and got all sorts of strange responses...
In the Amiga OS (now THERE was a great OS) you could define symbolic
paths that all software including SuperBase (quite a good RDBMS) could
use - so you could have My_Main_Database and My_Handy_Lookup_Tables and
so on configurable. The nearest that M$ OS has are things like
MyDocuments and shares - but you really need to be able to define shares
within shares.
It would be handy to have a "directory" / "module" concept in CS
databases - that is, be able to put tables into logical groupings within
one CS database - maybe already there?
Jim Hargan
/child/ really blows my mind. And it makes perfect sense in the Paradoxian
Universe.
My problem is: your approach is the result of a well-thought-out design. My
approach is the result of random hacking. Example: so I have a travel diary
app, just for me, very usable. Hey! I could link it to my main photography
database and suck in all the photos I took that day! Then I could link it
to the invoice database and see how much money I made! (If any :-( .) Very
cool! So I now have yet another subdirectory, aliased as :TRAVEL:.
I have 13 such sub-databases. And that's how it works in Happy Hacker Land!
I am irritated by your discussion on how it could all work anyway, mainly
because it would make Windows a really neat environment if it ran that way,
but it doesn't. Nevertheless, I am left with the nagging feeling that it
*could* work, and maybe it's only a rainly Sunday project away.
Well, nothing wrong with dreaming. In ten days I go to Prince Edward
Island, one of the most beautiful spots on the planet, for four weeks. Yay!
--
Jim Hargan
Steven Green
don't you just hate that? (vbg)
Jim Moseley
Jim,
>So I now have yet another subdirectory, aliased as :TRAVEL:.
>I have 13 such sub-databases.
This might help you. If your forms' data model doesn't use aliases when
defining the table (in effect, defaulting to :WORK:), it will open the tables
from the same folder as the form, regardless of where :WORK: really is.
In your case, you could copy the form to each of your 13 sub-directories,
and each would point to their local data without needing 13 aliases.
For example, create a form called Invoice.fsl, with a data model containing
:WORK:Invoice.db. Copy this to ..\Travel and ..\Contracts.
When you open :Work:Invoice.fsl, it uses :Work:Invoice.db
When you open ..\Travel\Invoice.fsl, it uses ..\Travel\Invoice.db.
When you open ..\Contracts\Invoice.fsl, it uses ..\Contracts\Invoice.db.
HTH,
Jim Moseley
Robert Molyneux
> Gotta tell you, your information on setting the work directory to the
> /child/ really blows my mind. And it makes perfect sense in the Paradoxian
> Universe.
>
> My problem is: your approach is the result of a well-thought-out design.
>
> Well, nothing wrong with dreaming. In ten days I go to Prince Edward
> Island, one of the most beautiful spots on the planet, for four weeks. Yay!
>
> --
> Jim Hargan
>
Try Lord Howe Island.
When you stand in the water on the beach, fish come and nibble your toes.
If you clap your hands, birds come out of the undergrowth to see who's
there.
Larry DiGiovanni
> OK, so after playing around with ObjectPAL for about an hour, could
> someone show me how to create a cascading referential integrity link
> on a field TransactionID in a parent table called Transactions and a
> child table called TransactionDetails? In one of those articles on
> www.thedbcommunity.com called "Do It Yourself Referential Integrity",
> the author declines to show a working code sample because it is
> unreliable. Well, I'd still like to know how. I don't care if it's
> unreliable.
Dwight:
If you have ObjectPAL, then we assume you have access to a full copy of
Paradox. You're better off interactively restructuring a table in Paradox
than trying to do it in code. Even in non-Paradox environments, it is
unusual to have application code run DDL, and for what you described
earlier, you are only modiying two tables.
If you are trying to code for a release package, this is typically
accomplished in Paradox through code that renames table1, puts the new
structure of table1 in place by copying an empty table to it, then adding
the existing data back from the renamed original table. You'll need to
manage the RI widows and orphans during this process as well.
As far as working code for RI, again, if you have Paradox, the on-line help
may have an example.
--
Larry DiGiovanni