Your _context has either not been initialized or your Order table has no records in it. Put a breakpoint on the line that throws an error and hover over _context to see if it is null and check to see if the table has rows.

@Mr.Brownstone I know there is data in the Table as stated in the SO question "I even have the ability from the SQL Server Object Explorer (in Visual Studio 2015 Community) to "View Data" that is in both tables." my question is what should I be drilling down into within _context during debug? to find where it stores the records.

You didn't ad a reference to the SO question so I couldn't see what you previously posted. The stack trace for the exception will point to where the exception is being thrown. Can you post it?

@Mr.Brownstone its in the first paragraph of this post, also I added what I could from the _context drilldown at the bottom of this question, so that maybe it will show you something that has no meaning to me.

My mistake I missed that. So the problem occurs when it is trying to convert the result set to the list. Two things then, the first, hover over the Order DbSet - that will give you the query being issued, copy it and run it against SQL Server to ensure you get data, second, check that the properties of your model matches the columns of the database in terms of being able to accept nulls.

From what I can see on this thread: github.com/aspnet/EntityFramework/issues/6818 it is down to a property not being marked as nullable on the model. Also it could be this one github.com/aspnet/EntityFramework/issues/5112 where the root of the problem was an invalid binding on the model.

@Mr.Brownstone OMG you are a lifesaver, I was going to redo the who table, and it still wouldn't have fixed that. The issue was I have 3 DateTimes (Ordered,Filled,Delivered) and only Ordered is the only one set to NOT NULL. So this being the first time I every experienced this because from what I see you never have to declare nchar/nvarchar as string? nullable. I was unable to figure out from all the drill downs in DbSet where the actual query information was though. You want to make your comment an answer and I will accept it?

@Mr.Brownstone on a side note you can use the []() setup for links in comments as well, though it doesn't reduce characters used it makes for a cleaner read.

Hi Edward

Hi

I just saw your comments on the questions so I decided to invite you to a chat as long conversations are not allowed in the questions themselves

Have you resolved the issue since posting or do you still require assistance?

Well I have figured out the issues. But not sure why they are issues

OK

So know the issue allows me to fix or work around but not necessary understand it

So the virtual properties represent foreign keys in the database, this is how EF handles them in code. They are actually overrides later by EF so when you call the property it then loads it from the database or EF cache.

I put a think not only on SO, but gethub and sent in a VS report on the fact EF login validates against NormalizedUserName and not NormalizedEmail. Even though the template for Login.cshtml tells the person trying to login to use Email

Doesn't the class property that is the foreign key also need the [System.ComponentModel.DataAnnotations.ForeignKey("Company")] above it

And so without the virtual Company Company { get; set; } that throws the update issue?

Also do you or do you not use virtual in the public virtual DbSet<Order> Order { get; set; }

Sorry, I'm just trying to research your problem.

thats fine

In regards to the virtual modifier, it can get complicated, for each class that represents a table, such as Order, EF creates a proxy class called Order_1234 or something similar - this class derives from your own but overrides the virtuals

if you do not define a property as virtual it does not know it is a foreign key unless you then start using the data annotations and/or setting the mappings yourself in the model context

I'm looking into the Login issue for you - I do not use it myself as I only write apps for internal company network

Also, I don't like EF as it does not support all SQL Server functionality - thats not to say I haven't used it, it is fine for basic stuff but when you get complicated EF is just not up to the task

Yes I am just making up a little site for possible employers to look at in reference to ability/skill in place of minor work experience for programming/database

I only like to use the EF template against a database to store the user information that is separate from the other data, as it doesn't provide a lot I wouldn't need to write myself

Using another database for the meat and potatoes of datawarehousing

So the problem you are facing looks like it was implemented deliberately to resolve a previous problem: github.com/aspnet/Identity/issues/351

that isn't the issue

that is where they added two new fields into the aspnetuser table

so there isn't an upper lookup

I think its denormalizing the table to help with network performance

Sorry, I was referring to this specific line: "FWIW, we supposedly don’t do this anymore in recent builds of Identity 3.0 (i.e. the version we maintain in this repo). Instead we compute a normalized representation of the user name and we store it in a separate column so that lookups by normalized user name should now be sargable."

The issue I found is upon you register a new user and the template as is places username = email

but I have created a new property display/input for user registery for them to supply their own username

can you post the template?

do you have VS?

Yes

I mean there is alot of code to just paste. If you rather just setup new ASP.Net Core WebAPI with individual account verification

Give me a few minutes

when in login screen there is only label/input of Email and Password

put after creating the app and setting a connectionString to a DB to test this, run the generic app, register a user, log off, log back in by email. It works. Now change NormalizedUserName in the DB, and try to logoff/login again and it will fail

Yes it will do that because of what I mentioned earlier about the EF Cache

If you want it to pick up the new NormalizedUserName you will need to refresh your cache. EF is not smart enough to know when you change a database record, it expects to do it itself

So EF keeps a copy of each record in memory to reduce the amount of times it calls the database. If you update the record in the database EF will not know that the one in memory also needs to be updated unless you flush your cache.

Once the cache is flushed, EF will then start to load records from the DB into memory again as they are requested.

Yes but I resave/rebuild/ and rerun each time I make changes and test again

Are you using IIS or IIS Express?

Well what comes with Microsoft server 2016 essentials

Probably express.

What are your test steps?

I still feel this is cache related but I want to be sure.

so programs say II 10.0 express

ok so run the program

register a user

log off, log back in

I will need time to try and reproduce your problem - in essence, you do not want the email to be the normalizedusername, correct?

right but I was also showing the template just puts email into username

so showing you can logout and login with the email verifies everything works.

then YOu would run a sql update to change username

Yes, but the fact that the email is the username is by design and so that is not a defect, the problem is that once you change the username in the db, you cannot log back in with the new username, correct?

so if you change username in the db, to something that is not email formatted, you will seee in login page you cannot even put it in

so then just try to login with what you put in for email and it should fail

OK, so why can't you just change the validation routine in AccountViewModels?

When you login to any site its normally by email, unless by an external social site login

But for some reason EF is validating login based on NormalizedUserName even though the text Microsoft team put in for login view asks for email

Like I first mentioned I have the work around but its not doing what it should be doing and validating based on email

taking out [EmailAddress]

But as I said, that is by design, it is not a defect it is just not functioning how your particular case needs it to - in which case you would need to code around it to meet your particular needs

validation

I don't understand why you think its by design?

If they code a login page asking for email, and they added two new fields in AspNetUser table to include NormailzedEmail and NormalizedUserName, why would they not be validating against NormalizedEmail instead of NormalizedUserName

I understand your confusion, especially as both fields can actually contain the same value, but they have two different use cases. NormalizedUserName is used solely for Authentication, NormalizedEmail is used solely for password recovery

ok well I have given a user the ability to input a Username that displays in the upper right. But to enable login with email and not UserName, is there a way to override String.ToUpper(UserName) from being inserted into the NormalizedUserName field and use String.ToUpper(email) instead?

I am trying to find the source code for the identity framework so that I can look at what is happening internally. When I find out I will let you know.

ok, cool, thanks. Hope this isn't burden on your time

Not a problem - also have a look at this project, it uses identity without EF: code.msdn.microsoft.com/vstudio/…

When I was first trying to learn Asp.Net, (and I tend to get side-tracked when I tried to get to indepth on something) I was looking into creating a custom password Hash method to override EF's preloaded one. SO question that was trying to get help to that end and ended up just dropping interest with no one supplying and answer.

don't worry about it. finally got a little something up and working properly personal site