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
|
I ran across this today and hope that you guys have an answer for me. I am using the nightly build of the enterprise edition as of 6/31/2009. Example: I have an Activity entity that has two properties - both which are of the same Value Type (Schedule). So, in summary an Activity has a "WorkSchedule" and a "OutOfServiceSchedule". When I formulate a LinQ query that uses the WorkSchedule property in its where clause, the sql that gets emitted is incorrectly formulating a TSQL where clause that is investigating the OutOfServiceSchedule property. Attached is a repro of the issue. No database is attached as you can simply examine the SQL output to see the problem. |
|
|
Thanks for letting us know about this bug. I have committed a fix and this will be included in nightly builds dated 4 August 2009 and above, available from about 1430 GMT. Please let us know if you still see problems. |
|
|
Ivan, The new build addresses the SQL issue although the LINQ queries which executed before (although using the incorrect SQL) now are throwing exceptions. The repro I previously attached throws the following exception now: {"Unable to cast object of type 'Mindscape.LightSpeed.Querying.LogicalExpression' to type 'Mindscape.LightSpeed.Querying.PredicateExpression'."} Here's the query: var result = (from activity in unitOfWork.Query<Activity>() where activity.WorkSchedule.StartDate > beginHorizon where((activity.WorkSchedule.StartDate >= beginHorizon && activity.WorkSchedule.StartDate <= endHorizon) || (activity.WorkSchedule.EndDate >= beginHorizon && activity.WorkSchedule.StartDate <= endHorizon)) select activity);Any ideas? |
|
|
Hello Aaron, Sorry about this. I had reproduced the error with a simpler test case and hadn't double-checked against your original repro. This is now fixed and the fix will be included in the 6 August nightly build, available from about 1430 GMT. |
|