I realize I am the new guy and do not have a thimble full of knowledge compared to most of you, but this is the response I received after doing a bug report and attached video for a problem with Dialogs and multiple primary keys:
Really.....very problematic? PostgreSQL seems to handle it quite nicely and has no problems making sure the row is unique via two primary keys. You know PostgreSQL, that free program you download off of the internet. Since PostgreSQL is the backend and handling the details of constraints, etc., why does Alpha even worry about it? My biggest question of all, why does Alpha work fine in some areas, such as row expander, with multiple primary keys, while other areas such as Dialogs with repeating sections not? Therefore, there is a problem in your builder, or you need to copy the code out of row expander into dialog repeating sections. If you can't have multiple primary keys, why are there 5 rows in "Linking Fields" portion of Data Binding? I just can't fathom why it is "very difficult to insure they are unqiue" This seems like database 101 to me.
So does everybody out there have an autoid column in each table whose only purpose in life is to be a unique identifier?....when the other two columns in the database which have to be there for lookups anyway, say the same thing when combined? This is a problem for me because my database is multitenancy and requires at least two primary keys for every table and therefore will have this unique row link column in every table. What does an Alpha developer do if he/she has a transaction table and didn't allow enough room for expansion of autoid's? Seems like you are building in a Y2K type of problem that someday, next year, next decade, somebody will have to deal with when you run out of room for autoid's?
Somebody please tell me have this all wrong and I just didn't do _____. I have to go do my breathing exercises and then modify my entire PostgreSQL data model.
Andrew
We apologize for the slow response, but there simply isn't enough information for us to test this. Whatever value you are using to link tables, the values must be unique. Using multiple primary keys is very problematic in any database and normally not recommended as it is often very difficult to insure they are unique. We are confident there is no problem in the builder.
However, the only way we could evaluate your problem is with a test dialog and sample data that shows the problem.
We apologize for the slow response, but there simply isn't enough information for us to test this. Whatever value you are using to link tables, the values must be unique. Using multiple primary keys is very problematic in any database and normally not recommended as it is often very difficult to insure they are unique. We are confident there is no problem in the builder.
However, the only way we could evaluate your problem is with a test dialog and sample data that shows the problem.
Really.....very problematic? PostgreSQL seems to handle it quite nicely and has no problems making sure the row is unique via two primary keys. You know PostgreSQL, that free program you download off of the internet. Since PostgreSQL is the backend and handling the details of constraints, etc., why does Alpha even worry about it? My biggest question of all, why does Alpha work fine in some areas, such as row expander, with multiple primary keys, while other areas such as Dialogs with repeating sections not? Therefore, there is a problem in your builder, or you need to copy the code out of row expander into dialog repeating sections. If you can't have multiple primary keys, why are there 5 rows in "Linking Fields" portion of Data Binding? I just can't fathom why it is "very difficult to insure they are unqiue" This seems like database 101 to me.
So does everybody out there have an autoid column in each table whose only purpose in life is to be a unique identifier?....when the other two columns in the database which have to be there for lookups anyway, say the same thing when combined? This is a problem for me because my database is multitenancy and requires at least two primary keys for every table and therefore will have this unique row link column in every table. What does an Alpha developer do if he/she has a transaction table and didn't allow enough room for expansion of autoid's? Seems like you are building in a Y2K type of problem that someday, next year, next decade, somebody will have to deal with when you run out of room for autoid's?
Somebody please tell me have this all wrong and I just didn't do _____. I have to go do my breathing exercises and then modify my entire PostgreSQL data model.
Comment