This thread looks to be a little on the old side and therefore may no longer be relevant. Please see if there is a newer thread on the subject and ensure you're using the most recent build of any software if your question regards a particular product.
This thread has been locked and is no longer accepting new posts, if you have a question regarding this topic please email us at support@mindscape.co.nz
|
Hi Guys, I've encountered the weirdest issue. I have a small table (In SQL Server 2008) which is connected to a base table through class table inheritance. This table has two fields. A Name field of type string (NVARCHAR(50) in the database) and an IsDefaultTemplate field which in the model is a Boolean field and on the database side is a bit field. Both fields are not nullable. I've got some data in this structure and when querying the data, everything looks fine. Now when I want to get all data from this table (TemplateAgreement) from the Lightspeed model (through LinqPad), I get the following exception: LightSpeedException: Unable to materialize field [IsDefaultTemplate] on type [SMS.EBA.EA.EnergieOpMaat.Model.TemplateAgreement]: field is type 'System.Boolean' but database returned type 'System.DBNull'. Check your table has an Id column and that your mappings are correct. See inner exception for details. The SQL that gets generated (in LinqPad) works fine and gives me the correct data, including the correct data for IsDefaultTemplate (some records have False (0) and some have True (1)). When I use the following statement, I DO get the actual data for the IsDefaultTemplate field: UnitOfWorkScope.Current.TemplateAgreements.Select(t => new {Name = t.Name, IsDefaultTemplate = t.IsDefaultTemplate}); I've tried dropping and recreating the field, both from the model and from the database, but to no avail. When I make the IsDefaultTemplate field in the entity nullable, it works, but the actual data in the column is NULL. Any ideas? Unfortunately I have not yet been able to reproduce the issue. Kind regards, Robert
|
|
|
This can occur if there are duplicate field names in the class table inheritance hierarchy -- for example if there is a sibling class which also declares a Name property mapped to a Name column. The workaround for this is to rename one of the properties (e.g. rename Name to AgreementName). |
|
|
Just to be clear, this problem does not necessarily manifest on the field with the duplicated name -- thus, two Name fields can cause an error on the IsDefaultTemplate field. (Basically the duplicate name throws off LightSpeed's internal indexing, so it ends up trying to load subsequent fields from the wrong positions in the data reader.) So look for *any* duplicate names across the hierarchy, not just Name or IsDefaultTemplate. |
|
|
Hi Ivan, Quick reply as always... Can this also happen on another field? I.e. The Name field is duplicated, but I have the problem on the IsDefaultTemplate field? If not, this is not the problem, as that field (IsDefaultTemplate) is the only one (in the inheritance hierarchy and the complete model). I did try to rename the IsDefaultTemplate field to something obscure to make sure we didn't have this clash (as I did see a post where you mentioned this solution), but then I still had the same problem, now with this obscure name (I chose something like IsDefTmplxxyy. Not likely to conflict). I will check if the other field in that entity (Name) has a duplicate somewhere in the hierarchy, just to be sure. Kind regards, Robert
|
|
|
Wow, got an answer before I posted the answer ;-) Will check the duplicate name issue. I assume Lightspeed's own fields (Id, Error, etc.) are excluded from this issue, right? Robert |
|
|
Yes, that's correct. |
|
|
Hi Ivan, I've gone over all the fields in the class table inheritance hierarchy, but have found no duplicates. To make sure, I also checked for fieldnames that where the same as fields on entities that have a relationship with any of the entities in the hierarchy and for the few that I found, I changed the name, but to no avail. Did I mention the inner exception shows 'Specified cast is not valid'? It does probably have something to do with a shift in the mapping, but is there a way to find out which one it is? Robert |
|
|
Hi Ivan, Just to be complete, here's the complete error message. Hope it helps to figure out the issue:
|
|||||||||||||||||||||||||||
|
|
Unfortunately, even if we can figure out which field is getting shifted into the IsDefaultTemplate "slot," the actual problem is probably happening somewhere earlier in the field list. We don't really have a good way for users to diagnose where the mapping is going awry (if we did, we'd have prevented it from happening!). I think the best thing is for you to post the class hierarchy and database schema (and ideally your test data) and for us to see if we can diagnose it. |
|
|
Hi Ivan, I can do that, but I then have two options: 1. I strip the model and maybe even rename stuff to make sure I don't post any intellectual property with the chance I somehow 'fix' the issue. 2. Send you the complete model/database #paranoid mode=on Since I, as all developers, am strapped for time, I prefer option 2, but then I don't really want to post it, but send it to you personally (by email). Is that an option? If so, I assume you are bound to some sort of Non-disclosure clause for this information? #paranoid mode=off Kind regards, Robert
|
|
|
We understand the need for confidentiality. We're not willing to get into the business of signing NDAs, but I can promise that we won't share your model or data with anybody, or make any use of them except for resolving this issue. If that's sufficient, send me the model, database and problematic query (as a console application or NUnit test) at ivan @ the obvious domain name. Our email provider silently discards any email containing binaries, even in a zip file, so either rename the zip file to have a non-zip extension, or ensure all binaries are removed before sending (or both). |
|
|
Hi Ivan, I wasn't asking you for a signed NDA. Your promise is sufficient as far as I'm concerned, so I'm going to send the data to you. Since the 'problematic query' is nothing else than retrieving the data from the TemplateAgreement table, would using LinqPad be an option for you? With your driver connected to the model, a query with 'TemplateAgreements' would already give you the error. Is that acceptable to you? (since you wrote the linqpad driver, I assume you have the app ;-)) Kind regards, Robert |
|
|
It's easier for us to test in an isolated environment than in LinqPad. However, I'm assuming that the same problem does show up in your real code -- it's not specific to LinqPad, right? (I'd be pretty astonished if it was!) So if you can confirm that the following code: var tas = _unitOfWork.TemplateAgreements.ToList(); reproduces the error, then that's enough for me! |
|
|
Yep, that should do it. As long as you request all records from that entity, that should reproduce it. I'm working on packing everything up. Should be with you shortly.
|
|
|
Thanks, Robert, received and reproduced. It’s a bug with the handling of multi-field value objects in other parts of the hierarchy. In your case a couple of TemplateAgreement's sibling classes have value object members, and this is throwing out our indexing (we appear to have an assumption that any field that is not used in the entity we're loading will be represented by exactly one database column, whereas your value object type is represented by two database columns). |
|
|
Hi Ivan, Good to hear I wasn't doing something completely stupid that caused this ;-) (At least not this time). Thanks again for the quick support. Looking forward to a solution :-) Are you saying that, if we get in a pinch, we could integrate the Value objects into the table (as regular fields) and it should be OK? Kind regards, Robert |
|
|
Yes, as far as I can see breaking out the value objects into regular fields should work. |
|
|
Hi Robert, We have now fixed this issue (and, we believe, the duplicate names issue I mentioned earlier), and it will be in the 12 November nightly build, available from about 1200 UTC. Thanks for alerting us to this issue and of course please let us know if you still see problems. |
|