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 All, This query fails with Lightspeed 4.0 and nightly 4.0.1103.19500 (22-1-2012).
I also tried without using the lets but having the path directly in the query. These are references to other tables so I am not even sure if this is possible. Thanks! |
|
|
Can I do something to make this a more useful report / inquiry? Thanks, Dennis |
|
|
Hello Dennis, We're still investigating this but it appears to be a problem in the LINQ provider and we believe there is a workaround using query objects. It is a bit ugly and not entirely database-agnostic but hopefully it will do for your immediate problem. Your query can be rewritten using query objects as follows:
Most of this should be reasonably easy to follow -- the only tricky bit is doing a by-year comparison on a date-time column. This is database-specific. On SQL Server it involves calling the DATEPART function which is rather messy because it needs you to pass in an extra string argument ("YEAR"); on some other platforms such as MySQL it is a lot simpler as you just call the YEAR function ( If you are on SQL Server or another 'messy' database you should be able to wrap up the complicated
Let us know if you need any more info or need any help to get the query objects technique working! |
|
|
Thanks your response, I currently have a different less efficient work-around, which I hope to revert after the issue has been fixed, if not when we go into production I will try what you describe (sorry, a bit on a tight schedule already). However, would it help if I create and attach an isolated test case, with a reduced Lightspeed model and the crashing query in a test program, or unit test? Please let me know and thanks for the response. (For the record, we are on MS SQL Server, and this will be the only target). |
|
|
We do normally prefer isolated test cases, in the form of NUnit tests or console applications, but in your case we know how to reproduce it so it's probably not worth you taking the effort to create a repro of your own. We do appreciate the offer though! Regarding this issue, we don't have a timescale for the LINQ fix (we're still quite heavily loaded at the moment) so I'd advise you to expect that you'll have to use the query objects workaround (or stick with your current workaround) -- don't rely on getting a LINQ fix especially if your schedule is tight. Therefore you may want to implement the query objects workaround sooner rather than later, so as to avoid making a last-minute change with the risk that entails. |
|
|
Hi Ivan, Ok, no problem. Thanks for your response! Just out of curiosity, am I the first reporter of this particular issue, or have you verified that this is the same case as previously reported issues? Also, when it is fixed later on, will it have a clear change history entry? (I follow the blogs, so I'll pick it up then). Cheers, Dennis |
|
|
You are the first reporter of this issue. I can't make any promises about how it will be presented on the blog (the blog posts are derived from our source control logs) but if you keep an eye out for 'multiple let statements' or 'chain of traversals' then that should see you right. However if during analysis we strip the bug back to a more basic case (e.g. your note that it happens even if you convert the lets to traversal chains) then it might appear as something different. But whoever does the fix should be aware of this thread and will hopefully remember to make an appropriate commit comment or simply to post here! |
|
|
Super cool, I'll keep an eye out! Thanks! |
|