Best Practice Question

[Jason MacKenzie]

Just curious about some suggested approaches to this issue (which must be
common).

A user goes to a page to create a new project. We have a requirement that
they must see the project number before saving.

We fetch the next id from a table. The issue is that users must be able to
upload attachments to the project before saving but if they do that and
don't ever save the project we end up with orphan records in the database
and unneccessary files to the server.

Thanks for any suggestions,

Jason

 

[Guest]

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnbda/html/bdadotnettransact1.asp

 

[David Lozzi]

Another issue I see is that if you are only fetching the next ID, and not
creating a record on it, what will stop another user at the same time to
create a project with the same id? I'd recommend creating the new record,
pull that ID, then load up everything. If the user clicks cancel, simply
delete the project record and make sure cascading deletes are enabled to
clear the remaining tables. Regarding the files that were uploaded, I'd
upload all files to a folder named by the project ID, even only for temp
purposes, so you can just delete the entire folder.

I've had to do similar and that's what I've done and it works well!

 

[Jason MacKenzie]

Well - we would increment the next id. So no two projects could have the
same id.

And they won't necessarily hit a cancel button. They will most likely
forget about it and close the browser at the end of the day or just turn off
their laptop.

 

[David Lozzi]

How will you increment it? By just adding 1 to the ID in your script? Or
increment it in the DB?

You could write some javascript taht catches the window closing and prompts
stating changes will be lost if not saved, then if they click OK, delete all
data and close the window.

Another option is to schedule something to check for data in SQL and files
and delete as necessary. If this is the case, What happens when someone
decides not to save, then someone else comes in afterwards before the clean
up? Will the second person have the same incremented ID? Will that be a
problem for the existing data?

 

[Jason Kester]

Sounds like you're getting the storage requirement mixed up with the
application requirement.

The application requirement is that half-baked records should never be
seen by users, including the user that is creating them. There's
nothing in your description that should prevent you inserting the
record and setting some sort of IsActive flag to false. Depending on
your requirements, you'll have to implement filtering at either the
database or presentation level to ensure that only active records are
available for display.

This gives you a real-live ID to attach your photos to, and the ability
to store those photo records without breaking any foreign key
constraints. It also saves you the effort of constructing a duplicate
storage mechanism for records at this stage, and it makes it a whole
lot easier to commit the record down the road, after administrative
approval or whatever your process involves. Simply flip the bit and
it's live.

Good luck!

Jason Kester
Expat Software Consulting Services
http://www.expatsoftware.com/