Hello;
I'm flipping an app to EDB1.8

I want to create a foreign key on a field

This code below  doesn't seen to work. I read the manual but these things have a tendency to elude me till I practice and practice:
Does anyone have a real work snippet of how to build a Foreign key with usng ALTER TABLE

Tia
Allan

ALTER TABLE  "callmaster"
CONSTRAINT "WorkCode" FOREIGN KEY ("WorkCOde")
REFERENCES "WORKTAB"("WorkCode")

Allan


Do it in EDBManager and then look at Explorer - SQL History and steal the code

Its dead handy when you find it

Roy Lambert

Roy Lambert <roy.lambert@skynet.co.uk> wrote:

Allan


Do it in EDBManager and then look at Explorer - SQL History and steal the code

Its dead handy when you find it

Roy Lambert

Roy;
In EDBmqnqager I am getting kicked in the pants. It won't let me create a constraint for the workcode field..
The target tabke can get set but the target Constraint field cannot. the app is looking for a constraint, the primary key only, in the "workTable".!?  Error 400 "The primary Key
constant "Primarykey" already exists". I am expecting a dropdown lost of all my indexes in the target table to choose from(constraints-parameters tab). I'm missing something here?

When I look at the SQL history I do not get even a bad SQL statment?

Allan

Allan


You won't get anything in the history until the sql executes.

I just tried it here and managed

ALTER TABLE "Career"
ADD CONSTRAINT "zx1" FOREIGN KEY ("_fkCompanies") REFERENCES "Companies" ("_ID") ON UPDATE RESTRICT ON DELETE RESTRICT DESCRIPTION 'dededed'

But EDBManager didn't present any list of indices to select from in the companies table. Just had PK in there (I name all the primary keys to PK)

Roy Lambert

Roy; thabnks for this
. I give it a go
Allan

Roy Lambert <roy.lambert@skynet.co.uk> wrote:

Allan


You won't get anything in the history until the sql executes.

I just tried it here and managed

ALTER TABLE "Career"
ADD CONSTRAINT "zx1" FOREIGN KEY ("_fkCompanies") REFERENCES "Companies" ("_ID") ON UPDATE RESTRICT ON DELETE RESTRICT DESCRIPTION 'dededed'

But EDBManager didn't present any list of indices to select from in the companies table. Just had PK in there (I name all the primary keys to PK)

Roy Lambert

Allan,

<< In EDBmqnqager I am getting kicked in the pants. It won't let me create a
constraint for the workcode field..
The target tabke can get set but the target Constraint field cannot. the
app is looking for a constraint, the primary key only, in the "workTable".!?
Error 400 "The primary Key constant "Primarykey" already exists". I am
expecting a dropdown lost of all my indexes in the target table to choose
from(constraints-parameters tab). I'm missing something here? >>

Yes.  ElevateDB only allows for the use of a primary or unique key
constraint as the target of a foreign key since it has to be assured that
the value will be unique or NULL in the table that is driving the foreign
key relationship.

<< When I look at the SQL history I do not get even a bad SQL statment? >>

Roy is correct - you cannot see anything in the history until the SQL
executes successfully.

--
Tim Young
Elevate Software
www.elevatesoft.com

"Tim Young [Elevate Software]" <timyoung@elevatesoft.com> wrote:

Allan,

<< In EDBmqnqager I am getting kicked in the pants. It won't let me create a
constraint for the workcode field..
The target tabke can get set but the target Constraint field cannot. the
app is looking for a constraint, the primary key only, in the "workTable".!?
Error 400 "The primary Key constant "Primarykey" already exists". I am
expecting a dropdown lost of all my indexes in the target table to choose
from(constraints-parameters tab). I'm missing something here? >>

Yes.  ElevateDB only allows for the use of a primary or unique key
constraint as the target of a foreign key since it has to be assured that
the value will be unique or NULL in the table that is driving the foreign
key relationship.

<< When I look at the SQL history I do not get even a bad SQL statment? >>

Roy is correct - you cannot see anything in the history until the SQL
executes successfully.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim;
Thanks for you help.
Here is my scenario: The Primary Keys in all of my tables is a GUID.  I do this to separate the Primary key from the rest of the data.  I want a unique Value here. So the “WorkCode” value
stored in my "Call master” table really won't reference the appropriate code in the “WorkTab” table.
I use this lookup in Drop down selectors on the Call Master screen.  I have a ton of these drop downs

So if I’m reading you correctly. I should replace the “Work Code” in the “Call Master “ table with the Primary Key Value from the “WorkTab” table..  (the GUID)

Allan

Allan


If I understood your post correctly then the answer is YES.

Roy Lambert

Roy Lambert <roy.lambert@skynet.co.uk> wrote:

Allan


If I understood your post correctly then the answer is YES.

Roy Lambert

Roy;

FUDGE!!!

Allan

Allan


Not at all. I simply thought you were writing in a foreign language

Roy Lambert