G.I. wrote:
Hi,
I want to know how to do the following if it's possible:
If I have a machine with counters. These counters will be reported often and stored in the database. Now I need a grid to show all the last counter readings of these machines. Now here's the tricky part. My SP I have at the moment is using some GROUP BY, SELECT IN etc. which somehow I know I will be able to convert to code using the DQE. But now I also have something like this:
ISNULL(MAX(table1.COUNTER - ((CAST(SUBSTRING('999999999',1,CAST(table2.number_of_ciphers AS int)) AS numeric(9)) + 1) * (table1.reading_lap -1))),0) COUNTER
ISNULL and CASTS are not supported. Should I just give up and keep on using this stored procedure to fill a collection of entities or should I try to write code to figure this out? The application should work for different databases, that means different stored procedures, which means more maintenance. That's way we want to get rid of most stored procedures, but hey, some very tricky stuff is being done by those...
Those things aren't supported (ISNULL and CAST). What you can do is create an IPredicate implementation (derive from the Predicate class) which allows you to emit this string directly into the query. Though it then still isn't cross platform, though these things probably never will be (SUBSTRING... CAST, ISNULL...)
UNIONS are not supported either. How is it possible for me to use two kinds of queries to fill one collection of the same type of entities? (Like a workaround for this).
Just fill the same connection with the second query. New entities not in the collection will be added to it. Entities you've already fetched into the collection will be ignored. If you;re using SelfServicing, please set entitycollection.SuppressClearInGetMulti to true before calling GetMulti
One other thing: LLBLGen use mapping from tables to entities. I am used to use entities with data from multiple tables and then store data in a single table. It seems like i have to change my thinking a lot and change to using multiple objects with relations to fill the data of one entity and update the table I think.....right?
Yes, though this will be addressed soon with support of inheritance, i.e. supertype/subtype entities, which means entities which are subtypes of other entities can thus be spread over multiple tables.
