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
|
We're experiencing weird behavior with a stored procedure which returns a list of records. First, create a new database. In this database create this table: CREATE TABLE [dbo].[Test]( To this table add 10 records: insert into Test (Di) values (10) Now add the following stored procedure to this database: CREATE PROCEDURE [dbo].[QueryTest] If you execute the above stored procedure in SQL Server Management Studio, the results are as expected (from 10 -> 1), however create a new project and drag both the table and the stored procedure onto a lightspeed model. Then run the following code: // .NET 3.5 (LINQ) This is where things become interesting, the console will now output (with latest nightlybuild) the following: D:\Projects\LSTest\LSTest\bin\Debug>LSTest.exe Now one could argue that this is, lets just say, not the record set we'd expect. Funny enough, the number of records is correct but it'll only retrieve the first record and duplicate that a lot of times. |
|
|
Hello, It looks as though your Stored Procedure is not returning the 'Id' for each row. You must include this as all LightSpeed entities need an Id. Update the SP to return that and then re-run your test it and should operate as expected. I hope that helps, John-Daniel |
|
|
If that's a requirement, why does nothing give an error that no Id is present? It actually runs the stored procedure, it generates a result set, but that set is broken.
|
|
|
This was a bug where a low-level component was silently converting a missing value to 0. This caused a broken result set because we kept seeing Id 0 and going "ah, we already have that one, so we'll use the existing entity instead of materialising a new one." I've committed a fix for this, so beginning with the next nightly build (available from about 1200 GMT), a stored procedure that doesn't return an Id column will cause an exception rather than a broken result set. |
|
|
That'll save someone else a few hours of debugging (I know it took me a bit to figure out). In a perfect world, a stored procedure (or view) result would not require an Id, but this is better then broken result set I guess. I say that because the result set that we generated with the stored procedure (not the simple one from this post) doesn't really have an Id to speak off, it's simply a combination of various tables/records/etc. It actually took a bit of playing around to see what value we could use as an Id. (due to the fact that it is a combination of a few full outer join's) Thinking about this while writing, I actually need to change the current Fake-Id as there's a chance of null values. |
|
|
[quote user="Jerremy"]In a perfect world, a stored procedure (or view) result would not require an Id[/quote] We can't avoid the need for an Id to materialise entities, because LightSpeed needs a way to identify entities (so it doesn't spin up two entities for the same row). If we had a way to call a sproc and materialise the results as non-entities (like projections do), that certainly wouldn't require an Id! We should look into that I guess -- thanks for the feedback! |
|