From a design POV why would you want to give up control and have the
backend responsible for something that takes a reply of, to provide you data necessary for the next set of inserts?
PKMasterID you generate via a GUID.
If that same key is required in 2,3,4+ other tables as FKMasterID, why not generate the pointer and then submit ALL the inserts at once within a transaction on the server? Or do you have procedures on the server that do your insert and all you need to do is pass the params for them?
On Sun, Oct 29, 2017 at 6:18 PM, < mbsoftwaresolutions@mbsoftwaresolutions.com> wrote:
On 2017-10-28 11:54, Stephen Russell wrote:
Disk space is cheap. Database schema changes are not. Updates require testing as well as validation in all of the UI and UX environments.
Indexes of int are easy and great. Indexes of Char, VarChar, or NVarChar are necessary. How the rdbms does such, and how the dba defines the index to accept insert as well as an update is where the true performance lies.
FabNet was designed with app-generated GUIDs using Craig Boyd's createguid logic. Classic FabMate was using auto-incrementing tables in VFP; I was thinking of just using auto-inc keys again (rather than varchar(40) guid keys).
[excessive quoting removed by server]