Help with Paradox 9 table schema

#11

as Tonty said, these are C+ questions.. the table format isn't the issue,
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:

Quote:

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..

Quote:

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

#12

as Tonty said, these are C+ questions.. the table format isn't the issue,
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:

Quote:

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..

Quote:

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

#13

as Tonty said, these are C+ questions.. the table format isn't the issue,
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:

Quote:

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..

Quote:

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

#14

as Tonty said, these are C+ questions.. the table format isn't the issue,
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:

Quote:

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..

Quote:

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

#15

as Tonty said, these are C+ questions.. the table format isn't the issue,
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:

Quote:

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..

Quote:

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

#16

Quote:

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?

#17

Quote:

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?

#18

Quote:

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?

#19

Quote:

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?

#20

Quote:

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?