Best way to keep track of our users as they're filling out our web form.

Question

Best way to keep track of our users as they're filling out our web form.

Viewing 4 posts - 1 through 5 (of 5 total)

You must be logged in to reply to this topic. Login to reply

Steve Jones - SSC Editor SSC Guru Points: 739542 More actions · Answer 1

I like identities, especially for something like this. A multi-page form, where you'll like to store the data after each page in case the session breaks and they need to reconnect. Identities make it easy.

If you have a heavy transaction load, GUIDs are nice because you can reduce a round trip. You can generate the GUId on the client and then insert it into the database. Since they're unique, you don't need to hit the db, generate a row, the return the ID to the client. Instead you can generate it on the client, insert it into the DB, not return anything and continue on.

If you have an AJAX type syste, this is nice.

Trying to generate your own unique key for people can be problematic if you're not 100% sure they will be unique. You have a good system, but have you thought about the fact the IDs can be for corporations or taxable entities and they might dupe the SSNs somehow? I'd be careful here.

themillimeister SSC Rookie Points: 29 More actions · Answer 2

Thanks for your reply Steve,

yeah I have thought about, what if they miss-type the last four of their social, or what if their session is broken. I know anything can happen. I do have validation set up so they HAVE to have all the text boxes filled before they can move to the next page, but, I know that when you're entering in numbers, such as a social, it's easy to transpose something. Then the horror would be going in there and fixing it for EVERY table for that one client before it's needs to be imported into our production database. I know that everything has to be right, or our, what we call our "intake" department, will be on the phone with them saying, "what's up with this bogus data?!" (-:

So, if you don't mind me asking, what would you do in this situation? Would you store session state in SQL Server? Right now I'm doing a search on that on Google. I've found a good article on that here:

http://www.developer.com/db/article.php/3595766

Steve Jones - SSC Editor SSC Guru Points: 739542 More actions · Answer 3

The thing to do is have a separate PK, either identity or GUID, and then store the data, but allow for mistakes. Give them a confirm, maybe on the next page (you just entered xxx, now please fill out these fields).

I'd also be sure to allow changes later to the extent that it makes sense. People do make mistakes, and good sites allow corrections.

I wouldn't worry so much about session, because browsers crash, machines restart, etc. Store it, but have it in a changeable state, meaning that you allow changes to it in the app. You might decide to lock things at some point, in which case, perhaps you'd add a flag that marks a row as "locked".

themillimeister SSC Rookie Points: 29 More actions · Answer 4

Thanks a bunch Steve, that is some GOOD information. If you don't mind, here is my layout for the Data_Demographics table. Please keep in mind that I am not a SQL guy...and I'm pretty new to development as well, as this is my first major project. lol (-: Ohhh yes, I am a proverbial newbie.

CREATE TABLE [Data_Demographics] (

[RowID] [int] IDENTITY (1, 1) NOT NULL ,

[UserID] [nvarchar] (22) COLLATE SQL_Latin1_General_CP1_CI_AS NOT NULL ,

[FirstName] [nvarchar] (50) COLLATE SQL_Latin1_General_CP1_CI_AS NULL ,

[LastName] [nvarchar] (50) COLLATE SQL_Latin1_General_CP1_CI_AS NULL ,

[Middle] [nvarchar] (50) COLLATE SQL_Latin1_General_CP1_CI_AS NULL ,

[Suffix] [nvarchar] (8) COLLATE SQL_Latin1_General_CP1_CI_AS NULL ,

[MaidenName] [nvarchar] (50) COLLATE SQL_Latin1_General_CP1_CI_AS NULL ,

[DateOfBirth] [smalldatetime] NULL ,

[SSN] [nvarchar] (9) COLLATE SQL_Latin1_General_CP1_CI_AS NULL ,

[CountryOfCitizenship] [nvarchar] (50) COLLATE SQL_Latin1_General_CP1_CI_AS NULL ,

[Gender] [nvarchar] (6) COLLATE SQL_Latin1_General_CP1_CI_AS NULL ,

[FinancialInstitution] [nvarchar] (1) COLLATE SQL_Latin1_General_CP1_CI_AS NULL ,

[USCitizen] [nvarchar] (1) COLLATE SQL_Latin1_General_CP1_CI_AS NULL ,

[CreationDate] [datetime] NULL CONSTRAINT [DF_Data_Demographics_CreationDate] DEFAULT (getdate()),

[NPNNumber] [nvarchar] (12) COLLATE SQL_Latin1_General_CP1_CI_AS NULL ,--National Producer number of insurance agents if they have one.

CONSTRAINT [PK_Data_Demographics] PRIMARY KEY CLUSTERED

(

[RowID]

) ON [PRIMARY]

GO

Sorry about all this extra stuff, I just copied the whole table into Notepad++. So, should I maybe change the UserID column to an Identity column? Steve, if you could just give this a quick look-over I would appreciate it very much.

Thank you very much, milli