PasswordHash NULL problem

[BobLewiston]

When I try to save a new (inserted) record in an SQL database, I get the following System.Runtime.InteropServices.ExternalException message:

Cannot insert the value NULL into column 'PasswordHash', table 'AdventureWorks.Person.Contact'; column does not allow nulls.
INSERT fails.
The statement has been terminated.

I have to either find out how to insert an appropriate value into the PasswordHash column OR make SQL Server Management Studio allow NULL in the PasswordHash column.

I discovered I could do the latter in SQL Server Management Studio via:

expand table | expand Columns | right-click PasswordHash column | click Modify | in lower right frame: toggle Allow Nulls from No to Yes

On doing so and then attempting to exit SQL Server Management Studio, I got a dialog box saying:

Save changes to the following items?
SQL Server Objects
<Server name>.AdventureWorks - Person.Contact

Clicking Yes elicited the following message:

Saving changes is not permitted. The changes you have made require the following tables to be dropped and re-created. You have either made changes to a table that can't be re-created or enabled the option Prevent saving changes that require the table to be re-created.

Contact (Person)

SQL Server Management Studio's onboard Help says I can override the "Prevent saving changes that require the table to be re-created" setting via:

Tools | Options | Designers | Table and Database Designers | Prevent saving changes that require table re-creation

I can try this, but I wonder if it might be dangerous. If for whatever reason the table can't be re-created, could I possibly destroy the original table in the process and then have to reinstall the AdventureWorks database? I don't want to have to do that, since for some unknown reason I had a very difficult time installing it the first time.

And ultimately, I don't want to sacrifice encryption, as I suspect might be the case if I allowed PasswordHash to be NULL.

So here are my two questions:
1. Could it be dangerous to try to re-create the table?
2. How do I get an appropriate value to put in the PasswordHash column?

For what it's worth, I'm working in a 32-bit environment with the following software:

SQL Server 2008 Express with Advanced Services
database: SQL2008 AdventureWorks (schema.table: Person.Contact)
SQL Server 2008 Management Studio Express
Visual C# 2008 Express

[ck9663]

These tables are usually related to one another. There are referential and domain integrity checks within the tables across the database. Although you might be able to change some of these, some of the relationships and checks might be broken because of your update.That's why it's not uncommon for sample data to be read-only.

If you're trying to create sample applications, you might just want to create a new database and table to work on.

--- CK

[BobLewiston]

ck9663:

Maybe the exact things I've proposed doing might break something, but the objective I'm pursuing is just to make the data NOT read-only, how ever that might appropriately be accomplished. Yes, the table I'm working with is related to other tables, but that's just about always the case with "real" (non-sample) databases, and they're successfully updated all the time. Surely I don't need to type in a whole new database just to accomplish that.

[BobLewiston]

ck9663:

But I would actually prefer just to supply values for the PasswordHash column, if I could figure out how to do that. You wouldn't by any chance know how, would you?

[ck9663]

We don't know what the column is used for. I assume it's a password that's encrypted using the one-way hash technique. You can store space if you want to, but an application that reads that field will decrypt it and will not be able to use your field.


--- CK

[BobLewiston]

ck9663:

These tables are usually related to one another. There are referential and domain integrity checks within the tables across the database. Although you might be able to change some of these, some of the relationships and checks might be broken because of your update.

Yeah, but wouldn't a password hash be only for applications that require passwords? All I want MY application to do is to edit, insert and delete records. It won't require any passwords. Do you think it's at all likely that relationships between tables could be compromised? I mean, maybe they could, I don't know, I'm asking you.

We don't know what the column is used for.

It's very odd. Every single record has a different hash and therefore a different password. I don't get it.

I assume it's a password that's encrypted using the one-way hash technique.

Agreed.

You can store space if you want to...

What do you mean by "store space"?

...an application that reads that field will decrypt it...

I don't think so. A hash should be easy to obtain from the text that you're encrypting (in this case, the password), but "extremely difficult" (read that as "virtually impossible") to decrypt back into the password.

...and will not be able to use your field.

I'm sorry, I don't understand what you're saying.

[ck9663]

Store space.

 
INSERT INTO table (column1) values (' ')
 
 

--- CK