>>>>Hello Victor,
>>>>
>>>>this is very interesting for me. Could you please be more specific on "design your tables properly"? What do I have to do?
>>>
>>>Mostly it's an integer PK for each table, because it's required for updates. It may work with other types of PKs, but generally then you lose support, because that's what practically everyone uses, so when you run into a problem you find only examples which may not work for you. Also, you may think of porting your RI rules, if you have created them in the database - foreign keys, triggers etc.
>>>
>>>There's also a matter of minimizing the traffic - for big lookups you may perhaps create two views, one narrow with all records but very few columns, for searches, and another one with all columns but only one record, for editing and updates.
>>>
>>>Or you can completely skip the views and go directly for cursoradapter, which does all of that but more openly, and much more under your control, so you can do whatever you want on any of before* or after* events (qv in help for CA).
>>
>>Lately I've been thawing to the idea of using GUIDs for PKs. Makes it easier to consolidate databases from multiple sites, or do consolidated reporting. Even if the customer originally swore up and down they would never need that ;)
>
>I've been doing them for years. You need them for replication. SQL Server's built-in default value newsequentialid is very fast for inserts.
>
>https://docs.microsoft.com/en-us/sql/t-sql/functions/newsequentialid-transact-sql?view=sql-server-2017

??? What? You need a Primary Key for replication, it can be a GUID, it can be a sequential id, it can be anything as long as it is a PK, I have one running for years with bigint as PK. (and you can use non transactional replication without PK)