Hi, scott_flex wrote: > Thanks for the reply... i probably will look into writing my own > implementation. Never really thought of it... > > Generating GUIDs on server, while i can do that, just makes more > sense if it's done in the flex app itself. >
No, it doesnt. > and yes... these IDs will be used as primary keys in my database... > at least that's the current design i'm thinking about. > Your kidding.. > I'm generating an XML document in my flex app, where each > node/element and its attributes represent a single row and child rows > in a parent child/foreign key relationship. > > When i call a web service, i get my xml document which contains pre- > existing primary keys but when i add elements that have not yet had > been persisted to the database i don't want to both send up my xml > data and then turn right around and pull it back down just so my new > xml elements/nodes have the correct primary keys attached. That's > especially important when i save/send up the xml a second and third > time. > > If i can assign my IDs earlier in the process, that solves that > issue. I still have to check pre-existence on my server side when i > actually commit my changes to either run an insert or update sql > statement. > What will happen with things like collision handling or other applications wanting to insert into the database in future etc? Do they have to ask you to generate them a PK with your "special actionscript function"? ;) Why not do something simple like assign a tempid on the client, do the all the DB stuff on the server and return a list of temp_client_id=server_side_id key/value pairs, then put those values back in the xml on the client? Should be simple enough. At least that way you are not generating database primary keys in your client app. You can also implement a strategy on the server side so your client app never gets a real database PK. cheers, shaun
