World Wide DBA

No, what I wanted to do wont work either.

One moment, I may have an idea

You are correct. Which means that what you want to achieve cannot be done. You must either use a global temporary table or refactor your code to work around the restrictions placed upon you by the system.

How so?

Hi

Thanks, updated my answer for you.

What error is it throwing?

No, you don't need to declare it beforehand, it'll get created when the statement executes.

@Paparazzi The deny is applied to any user or role that is not an administrator of that database.

Is anybody going to PASS Summit this year? It would be great to finally meet up with some of you!

@MaxVernon I saw your post on twitter today about the Data Driven event and Nokia, to be honest when he pulled out the iPhone I thought exactly the same :)

@Zane I will be attending but not speaking. I am hoping to speak at the next PASS event in Chicago though, it'll be my first time presenting.

Is anybody going to SQL Saturday Chicago?

Good Morning All

@dezso wow, I guess the guy didn't actually want an answer or an opinion on how he could improve ;)

@PaulWhite I'm originally from the UK

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

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.

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

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

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

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?

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

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

What are your test steps?

Probably express.

Are you using IIS or IIS Express?

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

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.

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

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

Give me a few minutes

Yes

can you post the template?

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."

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

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

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

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

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

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

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.

OK

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

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

Hi Edward

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.

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.

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?

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.