I've two tables:

OutputPackages (master)

|PackageID|

OutputItems (detail)

|ItemID|PackageID|

OutputItems comes with an index known as 'idxPackage' set around the PackageID column. ItemID is placed to auto increment.

Here's the code I am using to place masters/particulars in to these tables:

//fill packages table
for i := 1 to 10 do
begin
  Package := TfPackage(dlgSummary.fcPackageForms.Forms[i]);

if Package.PackageLoaded then
begin
  with tblOutputPackages do
  begin
    Insert;
    FieldByName('PackageID').AsInteger := Package.ourNum;
    FieldByName('Description').AsString := Package.Title;
    FieldByName('Total').AsCurrency := Package.Total;
    Post;
  end;

  //fill items table
  for ii := 1 to 10 do
  begin
    Item := TfPackagedItemEdit(Package.fc.Forms[ii]);
    if Item.Activated then
    begin
      with tblOutputItems do
      begin
        Append;
        FieldByName('PackageID').AsInteger := Package.ourNum;
        FieldByName('Description').AsString := Item.Description;
        FieldByName('Comment').AsString := Item.Comment;
        FieldByName('Price').AsCurrency := Item.Price;
        Post; //this causes the primary key exception
      end;
    end;
  end;
end;

This works fine as lengthy when i don't wreck havoc on the MasterSource/MasterFields qualities within the IDE. But when I place it, and run this code I recieve a mistake that states I have got a replica primary key 'ItemID'.

I am unsure what's happening - this really is my first foray into master/detail, so something might be setup wrong. I am using ComponentAce's Absolute Database with this project.

How do i get this place correctly?

Update

Ok, I removed the main key restraint during my db, and that i observe that for whatever reason, the autoincrement feature from the OutputItems table is not working like I was expecting. Here's the way the OutputItems table takes care of running the above mentioned code:

ItemID|PackageID|
1     |1        |
1     |1        |
2     |2        |
2     |2        |

I still aren't seeing why all of the ItemID values aren't unique.... Any ideas?

Does using place instead of append around the products table behave any in a different way? My prediction here would be that the append around the detail "sees" a clear dataset, therefore the auto-increment logic begins at one, the following record two, etc despite the fact that individuals values happen to be designated... just to another master record.

One solution I made use of previously was to produce a new table named UniqueNums that endured the following available record id number which i would use. When I used several, I'd lock that table, increment the worthiness and write it in those days unlock and employ. This may enable you to get round the specific problem you're getting.

To begin with the thought of autoincrement and setting ID's by code clash for me. The obvious road to go would be to create the key yourself within the code. Particularly with multi user applications that need master/detail card inserts it's difficult to unattainable the best key placed for that detail.

So produce a ID by code. When creating the table, set the ID area to primary key but no auto increment. If I am not mistaken Append can be used for that operation.

You also appear to iterate as the visual controls are enabled? (Item.Triggered) . But the procedure is a load process by character. For GUI performance you should look at, crippling db controls which are connected after which execute the operation. Finding yourself in the actualOrfine detail scope, this might be the problem that two other cursors not iterating not surprisingly.

Perhaps you have attempted to exchange Append/Place with Edit?
And skip the "FieldByName('PackageID').AsInteger := Package.ourNum" line.

I believe the M/D relationship instantly appends the detail records when needed, as well as sets the detail table's primary secrets.

That could also trigger the duplicate primary key error. The record has already been produced through the M/D-relationship whenever you attempt to Append/Place a different one.