>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, < [email protected]> 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] _______________________________________________ Post Messages to: [email protected] Subscription Maintenance: http://mail.leafe.com/mailman/listinfo/profox OT-free version of this list: http://mail.leafe.com/mailman/listinfo/profoxtech Searchable Archive: http://leafe.com/archives/search/profox This message: http://leafe.com/archives/byMID/profox/CAJidMYJyF3NAyiJpQn4-VEca+yq91B7uSBUEWpuPnx=lzms...@mail.gmail.com ** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious.
