Re: Populates with Customerid + 27
There is also another primary key, not to be confused with the primary key. In every other script, operation, whatever, the primary key has ALWAYS been an existing field such as 'customerid'. Here, the primary key is not an existing field, but a field that is unrelated to the table.There is no reference to exactly what the primary key is. Thus, at first, I was basing the primary key on my past experience of what a primary key is. Not complaining here. Rather stating what happened and that perhaps something should be added by Alpha to clarify this point and the point about how the 'primary key' is really the record number. Thus, when I reset the customerid, I based it on the record number, not lastname or any other factor. LOL, that was kinda by accident because when I initially split the original table into 3 tables, that was the only option for keeping the 3 tables linked on the same value. That is why when I run this table, the right record appears.
As for the other 2 tables, ouch. They both contain the customerid field but now, the customerid in table 1 does not match the customerid in table 2 or 3. Originally, the records in tables 2 & 3 were the same record number as table 1 and that hasn't changed. I 'think' I can reassign the customerid in 2 & 3 based on the record number and be ok. If not, then I'll have to start afresh, breakdown the original table again after assigning new id numbers. I also assigned id numbers in 2 & 3 but started those at 20 and 30 so those should be changed as well.
As far as this being a bug, not sure if it is; depends on Alpha's intent on how this was supposed to work. If not a bug or if a bug. there needs to be clarification as not everyone wants to start numerical ID values at 1. for existing data, it makes all the id numbers for a customer the same for each table if a 1:1 link.
There is also another primary key, not to be confused with the primary key. In every other script, operation, whatever, the primary key has ALWAYS been an existing field such as 'customerid'. Here, the primary key is not an existing field, but a field that is unrelated to the table.There is no reference to exactly what the primary key is. Thus, at first, I was basing the primary key on my past experience of what a primary key is. Not complaining here. Rather stating what happened and that perhaps something should be added by Alpha to clarify this point and the point about how the 'primary key' is really the record number. Thus, when I reset the customerid, I based it on the record number, not lastname or any other factor. LOL, that was kinda by accident because when I initially split the original table into 3 tables, that was the only option for keeping the 3 tables linked on the same value. That is why when I run this table, the right record appears.
As for the other 2 tables, ouch. They both contain the customerid field but now, the customerid in table 1 does not match the customerid in table 2 or 3. Originally, the records in tables 2 & 3 were the same record number as table 1 and that hasn't changed. I 'think' I can reassign the customerid in 2 & 3 based on the record number and be ok. If not, then I'll have to start afresh, breakdown the original table again after assigning new id numbers. I also assigned id numbers in 2 & 3 but started those at 20 and 30 so those should be changed as well.
As far as this being a bug, not sure if it is; depends on Alpha's intent on how this was supposed to work. If not a bug or if a bug. there needs to be clarification as not everyone wants to start numerical ID values at 1. for existing data, it makes all the id numbers for a customer the same for each table if a 1:1 link.
Comment