Steven Green wrote:

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.

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

Steven Green wrote:

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.

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

Steven Green wrote:

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.

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

On Sun, 17 Aug 2008 15:12:16 -0700 (PDT), dwightarmyofchampions (AT) hotmail (DOT) com
wrote:
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

On Sun, 17 Aug 2008 15:12:16 -0700 (PDT), dwightarmyofchampions (AT) hotmail (DOT) com
wrote:
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

On Sun, 17 Aug 2008 15:12:16 -0700 (PDT), dwightarmyofchampions (AT) hotmail (DOT) com
wrote:
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

On Sun, 17 Aug 2008 15:12:16 -0700 (PDT), dwightarmyofchampions (AT) hotmail (DOT) com
wrote:
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

On Sun, 17 Aug 2008 15:12:16 -0700 (PDT), dwightarmyofchampions (AT) hotmail (DOT) com
wrote:
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

On Sun, 17 Aug 2008 15:12:16 -0700 (PDT), dwightarmyofchampions (AT) hotmail (DOT) com
wrote:
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

On Sun, 17 Aug 2008 15:12:16 -0700 (PDT), dwightarmyofchampions (AT) hotmail (DOT) com
wrote:
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