Database error help

I am working on a website that is currently being hosted. The website was configured for admin,guest and members. Everything was working fine.

I made no changes to code. When I log in as admin I am able to navigate to most of the pages however I keep getting this error.

From the error it seems to say that some of the required fields are null but they are not.

---

Some of the required attributes of Person are NULL in the Persons table

Description:An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code.

Exception Details:System.InvalidOperationException: Some of the required attributes of Person are NULL in the Persons table

Source Error:

Line 141: While r.Read()
Line 142: If TypeOf r("id") Is DBNull Or TypeOf r("visible") Is DBNull Or TypeOf r("firstName") Is DBNull Or TypeOf r("lastName") Is DBNull Then
Line 143: Throw New InvalidOperationException(Messages.PersonRequiredAttributesMissing)
Line 144: End If
Line 145:

Source File:E:\web\cabletrades\htdocs\App_Code\People\SqlPeopleProvider.vb Line:143

Stack Trace:

[InvalidOperationException: Some of the required attributes of Person are NULL in the Persons table]
 SqlPeopleProvider.GetPersonsForApproval(String transactionTypeId) in E:\web\cabletrades\htdocs\App_Code\People\SqlPeopleProvider.vb:143
 AdminAccountApproval.Page_Load(Object sender, EventArgs e) in E:\web\cabletrades\htdocs\AdminAccountApproval.aspx.vb:42
 System.Web.UI.Control.OnLoad(EventArgs e) +99
 System.Web.UI.Control.LoadRecursive() +47
 System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint) +1061

---

Instead of If TypeOf r("id") is dbNull or ....

A person could try this

If r("id") is nothing or .....

hope this helps

DK

Database diagram support objects cannot be installed...

I can't make a diagram on our server(Win2003 x64,SQL 2005 Enterprise x64 sp2 3054).

I have tried to login as an admin and create a new db, but get the same message -

'Database diagram support objects cannot be installed because this database does not have a valid owner. To..'

Also tried to make a diagram from the ReportServer db.

Any suggestions?

Two things to check.

1. please make sure that db has a owner (as the error suggests).

2. please check your compatibility level.

|||

Thanks Meher for your reply.

1. Both of the databases I tried has a owner.

2. I'm pretty sure the compatibility level is 90 (SQL 2005) since one is created during installation(ReportServer) and the other is created as a new db in SQL Management Studio. (To be sure I will check next week)

Any other suggestions?

|||

Are you still getting the error message?. As you have mentioned check the compatibility level once again and if you are still getting the message we can look a bit further.

|||

The compatibility level is 90(SQL Server 2005).

|||

what role do you belong to?. pls check

ms-help://MS.SQLCC.v9/MS.SQLSVR.v9.en/uirfsql9/html/6fdecefb-7bd3-4203-a58c-36d46ee628bf.htm

|||db_owner |||

Hi olof,

can you please go through the steps outlined in section 4.8.1 in http://support.microsoft.com/?id=910228

As per the section in the article, looks like you might have to install the diagram support.

To create database diagrams, change the database compatibility level to 2005, install database diagram support, and then return the database to the desired database compatibility level.

MVPs, please correct me if I am missing something.

Thanks

Meher

|||

one other thing I forgot to mention is that the installation of support objects can fail if the database

has been attached or restored from another instance of SQL Server. In such a case there is a

possibility that the database owner name stored in the database may not be a valid logon for the

instance of the SQL Server on to which the database is restored to (or attached to).

I would suggest if thats the case then you can use the Alter statement to change the owner to a valid logon.

ALTER AUTHORIZATION ON DATABASE::your dbname TO yourdesiredlogin

(please see BOL for more details on ALTER AUTHORIZATION).

I would suggest doing through T-SQL than UI and see if it solves your issue.

Thanks

Meher

Database design problem

We have to design a database for UserInfo. We already have a user
table, and contains userid. There are three user type(ex. student,
teacher,admin), they have their own tables. i don't know how to add the
personal infomation field. One way is putting some common field into
the user table, the other is laying the infomation of subtype into
their own tables.Which is better?Is personal info the same for all types? is it present in all types? If yes,
feel free to add it to the user table.
MC
"Readon Shaw" <xydarcher@.163.com> wrote in message
news:1132886720.966817.144210@.o13g2000cwo.googlegroups.com...
> We have to design a database for UserInfo. We already have a user
> table, and contains userid. There are three user type(ex. student,
> teacher,admin), they have their own tables. i don't know how to add the
> personal infomation field. One way is putting some common field into
> the user table, the other is laying the infomation of subtype into
> their own tables.Which is better?
>|||yes, but what is the advantages of that?
MC wrote:
> Is personal info the same for all types? is it present in all types? If ye
s,
> feel free to add it to the user table.
> MC
> "Readon Shaw" <xydarcher@.163.com> wrote in message
> news:1132886720.966817.144210@.o13g2000cwo.googlegroups.com...|||Readon Shaw wrote:
> yes, but what is the advantages of that?
The same advantage as that of having a user table at all - to help you
to apply constraints against it and therefore ensure the integrity of
your data. For example, if you have a name or email address that's
common to all types of user you'll perhaps want to add a constraint
that the address or name be unique across all users. That's much easier
to do if they are all in one table.
In general, the fewer places in which one attribute can appear, the
fewer the opportunities there are for anomalies and incorrect data.
David Portas
SQL Server MVP
--|||Phew, thanks David, I was trying to come up with a short answer :).
In addition let me point out that the entity in this design is User, and
that 'additional' tables might be called 'derivations'. Since the
information you're adding to design is based on entity and not on
derivation, you should apply it there. And only there.
Am I making sense here?
MC
"David Portas" <REMOVE_BEFORE_REPLYING_dportas@.acm.org> wrote in message
news:1132916473.316709.85460@.f14g2000cwb.googlegroups.com...
> Readon Shaw wrote:
> The same advantage as that of having a user table at all - to help you
> to apply constraints against it and therefore ensure the integrity of
> your data. For example, if you have a name or email address that's
> common to all types of user you'll perhaps want to add a constraint
> that the address or name be unique across all users. That's much easier
> to do if they are all in one table.
> In general, the fewer places in which one attribute can appear, the
> fewer the opportunities there are for anomalies and incorrect data.
> --
> David Portas
> SQL Server MVP
> --
>|||MC wrote:
> Phew, thanks David, I was trying to come up with a short answer :).
> In addition let me point out that the entity in this design is User, and
> that 'additional' tables might be called 'derivations'. Since the
> information you're adding to design is based on entity and not on
> derivation, you should apply it there. And only there.
> Am I making sense here?
>
> MC
>
Intuitively that makes sense, yes. More formally, this problem is the
subject of a design rule that Chris Date calls the Principle of
Orthogonal Design, which is used to prevent certain types of redundancy
and anomaly. Roughly this says that integrity constraints should
prevent data being recorded in more than one table if there is some
non-loss decomposition of the same data into fewer tables. That doesn't
absolutely preclude the user name (for example) appearing in both the
Teacher and Student tables but it does require that there should be
some constraint to prevent the same person appearing in both. For
practical reasons it is therefore more efficient to implement one
column and one constraint in one table rather than some more complex
constraints across several tables.
See the following article for more discussion of this.
http://www.dbdebunk.com/page/page/622331.htm
David Portas
SQL Server MVP
--|||Just to be certain, i didnt really try to explain the logic to you David,
but to the original poster :).
MC
"David Portas" <REMOVE_BEFORE_REPLYING_dportas@.acm.org> wrote in message
news:1132923609.030176.20790@.z14g2000cwz.googlegroups.com...
> MC wrote:
> Intuitively that makes sense, yes. More formally, this problem is the
> subject of a design rule that Chris Date calls the Principle of
> Orthogonal Design, which is used to prevent certain types of redundancy
> and anomaly. Roughly this says that integrity constraints should
> prevent data being recorded in more than one table if there is some
> non-loss decomposition of the same data into fewer tables. That doesn't
> absolutely preclude the user name (for example) appearing in both the
> Teacher and Student tables but it does require that there should be
> some constraint to prevent the same person appearing in both. For
> practical reasons it is therefore more efficient to implement one
> column and one constraint in one table rather than some more complex
> constraints across several tables.
> See the following article for more discussion of this.
> http://www.dbdebunk.com/page/page/622331.htm
> --
> David Portas
> SQL Server MVP
> --
>