You can't. An entity MUST have a unique, immutable ID. It doesn't have to be defined as a primary key in the database, but the field or set of fields must uniquely identify the row, and its value may not change.
So, if one field in your entity, or one set of fields in your entity, satisfies these criteria, make it (or them) the ID of the entity. For example, if there is no way that a user can create two instances in the same day, you could make [createdOn, createdBy] the ID of the entity.
If - you don't have PK on the table- there is a logical combination of columns that could be PK (not necessary if you can use some kind of rowid)-- but some of the columns are NULLable so you really can't create PK because of DB limitation- and you can't modify the table structure (would break insert/select statements with no explicitly listed columns at legacy code)
Database Integrity Suggestion
Inconsistent database table and entity definitions: column 'OSUSR_5ib_Medewerker3.NAME' exists in database, but there is no corresponding attribute in entity 'Medewerker'.
I will try to fix it with DBCleaner, don't know what else to do, but isn't this a serious bug in the OutSystems Platform? If it let me change the name of an attribute, it shouldn't result in any error situation at all???
I'm also a newbie, testing Outsystems. I'm getting the same message, due to some database edits I made. I was going to try DB Cleaner, but when I went to install it I got a message that it is incompatible with my release of Outsystems. It looks like I could try it anyway, but I'm concerned it will only screw things up more. Suggestions? Thanks!
As you can read above in this post I was (and still am) experiencing the exact same thing. DB Cleaner didn't solve the problem for me. I think of it as a serious flaw in OutSystems, it really should be possible without warnings/errors to adjust the data model. I hope they'll fix it in one of the future releases, as soon as possible would be my suggestion. I guess we'll have to live with and ignore the warning as Gonalo Azambujo suggests :-)
Attributes using lists of values, built-in and user-defined types are mapped to single columns with a database type and length corresponding to the attribute type. The column name for such a simple attribute is the Physical Column Name value specified in the simple attribute definition.
Direct scoring (AVG_DIRECT_MATCH_SCORE): this method only takes into account the direct matches found with the rules. This group score is the average of these match scores. Pairs in the group that have not been directly matched by any rule are considered to have a score of zero.
Transitive match score (AVG_TRANS_MATCH_SCORE): this method takes into account the direct matches found with the rules, plus indirect transitive matches, which are computed. The group score is also the average of the match scores in the group.
For golden data (GD, GI, GX, GH), the submitter of the batch into which the record was created. For source and master data, the user who has created the record in a workflow, stepper, duplicate manager, or a user name loaded by the data integration process.
This field may be loaded in the SD table. If left empty, it is automatically set to the submitter of the batch.
For golden and master data, the submit timestamp of the batch into which the record was created. For source data (SD, SA, UM), the timestamp at which the source record was created.
Note that this field may be loaded in the SD table, but this value is not propagated beyond the SD table. If this column is left empty in the SD table, it is automatically set to the submit timestamp of the batch.
For golden data (GD, GI, GX, GH), the submitter of the batch into which the record was updated. For source and master data, the latest user who has updated the record in a workflow, stepper, duplicate manager or the user name loaded by the data integration process.
This field may be loaded in the SD table. If left empty, it is automatically set to the submitter of the batch.
For golden and master data, the submit timestamp of the batch into which the record was updated. For source data (SD, SA, UM), the timestamp at which the source record was created or updated.
Note that this field may be loaded in the SD table, but this value is not propagated beyond the SD table. If this column is left empty in the SD table, it is automatically set to the submit timestamp of the batch.
For basic entities, Semarchy xDM uses a single identifier, stored in a column named after the physical column name specified in the primary key attribute definition. This column will exist in all tables. The identifier is simply propagated into the hub from the source records.
When using ID matching, Semarchy xDM assumes a common identifier across all systems. In this case, this common identifier is stored in a column named after the physical column name specified in the primary key attribute definition.
This column will exist in all tables. When publishing data into the hub, the middleware loads this column with the primary key from the publishing system. This identifier is simply propagated into the hub, and matching is done using this primary key.
When using fuzzy matching, Semarchy xDM assumes no common identifier across publishers. There may be two different records with the same ID in different systems. There is a need to match the records and consolidate them under a golden record having a primary key generated by the system.
When publishing data into the hub, the middleware loads this B_SOURCEID column with a primary key value from the publishing system.If this primary key is a composite key in the source system, all the columns of this composite key must be concatenated into B_SOURCEID.
When the records are consolidated in a golden record (GD and GE tables), a system-defined primary key is generated and stored in a column named after the physical column name specified in the primary key attribute definition. This key is referred to as the golden record ID.
For a reference to a basic entity, the referenced key stored is simply the primary key of the basic entity.As a consequence, the referenced value is stored in a single column. This column is named after the physical name provided in the reference definition and is prefixed with F_. For example, F_COUNTRIES.
For a reference to an ID-matched entity, the referenced key is the same for all systems. As a consequence, the referenced value is stored in a single column. This column is named after the physical name provided in the reference definition and is prefixed with F_ (e.g., F_EMPLOYEE).
This information means that the contact John Doe references the customer with the primary key 1235 in the CRM publisher, and that Jane Smith references the customer with the primary key A3251 in the MKT publisher.
This information means that the contact John Doe references the customer golden record with the golden record ID 6598, and that Jane Smith references the customer golden record with the golden record ID 6556.
Several entities involved in an inheritance relationship have their data stored in the same set of tables. These tables store the superset of the attributes of the parent and all its child entities. The B_CLASSNAME column is used to identify the class (entity) of a record in a table.
For example, when Person and Company inherit from the Party entity, the resulting table is named after the parent entity (i.e., Party), and will contain all the attributes of Person and Company as well. In the GD_PARTY table, records representing persons will have B_CLASSNAME='Person'. When publishing person or company information in the SD_PARTY table, the middleware must set B_CLASSNAME='Person' or B_CLASSNAME='Company' accordingly.
I am trying generate typescript proxy using commerceproxy generator but it throws error "Commerce Proxy Generator failed due to the error: The entity 'SuspendedTransaction' does not have a key defined..".
Could you please share how you resolved this issue? I am facing the same problem. I am also using a custom entity and the key attribute has been specified for one of the data members. I get this error when trying to compile my RetailProxy project and when trying the access the retail server via IIS Express.
Loading core metadata from assembly file C:\Users\Adminb7a0354d41\Desktop\RetailSDK\References\Microsoft.Dynamics.Retail.Proxies.ExtensionsGenerator.9.17.19329.14\build\Microsoft.Dynamics.Retail.RetailServerLibrary.dll.
As soon as you define any OData new entity, you should also define primary key on some of its fields using 'Key' attribute. If your entity does not have natural primary key, most probably you need to use complex type instead of using the entity.
All Dynamics 365 Customer Engagement (on-premises) records have unique identifiers defined as GUIDs. These are the primary key for each entity. When you need to integrate with an external data store, you might be able to add a column to the external database tables to contain a reference to the unique identifier in Customer Engagement. This allows you to have a local reference to link to the Customer Engagement record. However, sometimes you can't modify the external database. With alternate keys you can now define an attribute in a Customer Engagement entity to correspond to a unique identifier (or unique combination of columns) used by the external data store. This alternate key can be used to uniquely identify a record in Customer Engagement in place of the primary key. You must be able to define which attributes represent a unique identity for your records. Once you identify the attributes that are unique to the entity, you can declare them as alternate keys through the customization user interface (UI) or in the code. This topic provides information about defining alternate keys in the data model.
7fc3f7cf58