Using FieldCompareSetPredicate on a temp table

Posts   
 
    
jia
User
Posts: 7
Joined: 10-Nov-2010
# Posted on: 10-Nov-2010 21:10:47   

I need to create a IN clause on a temp table:

IN (Select id from TempTable).

Is there a way to do that with FieldCompareSetPredicate? The temp table clearly doesn't have an Entity class associated with.

Walaa avatar
Walaa
Support Team
Posts: 14995
Joined: 21-Aug-2005
# Posted on: 11-Nov-2010 10:40:21   

Do you create the temp table using LLBLGen code? Or is it created by an external mean?

jia
User
Posts: 7
Joined: 10-Nov-2010
# Posted on: 11-Nov-2010 19:00:54   

It's created by an external mean, unfortunately.

Walaa wrote:

Do you create the temp table using LLBLGen code? Or is it created by an external mean?

MTrinder
User
Posts: 1461
Joined: 08-Oct-2008
# Posted on: 11-Nov-2010 20:42:30   

Is it an actual sql temp table (ie is the name prefixed with # (connection scope) or ## (global scope)) ?

Or is it an actual physical table which is created for a temporary purpose...?

Matt

jia
User
Posts: 7
Joined: 10-Nov-2010
# Posted on: 11-Nov-2010 23:18:32   

Sorry I didn't make myself clear. It's a physical table created for a temporary purpose.

MTrinder wrote:

Is it an actual sql temp table (ie is the name prefixed with # (connection scope) or ## (global scope)) ?

Or is it an actual physical table which is created for a temporary purpose...?

Matt

daelmo avatar
daelmo
Support Team
Posts: 8245
Joined: 28-Nov-2005
# Posted on: 12-Nov-2010 03:19:49   

jia wrote:

Sorry I didn't make myself clear. It's a physical table created for a temporary purpose.

If it's a physical table created by you, then you can add it to your LLBLGen project so you would be able to use it when constructing LLBLGen queries. Am I right?

If you don't do that, I don't see other option than use your own stored procedure. Then you can project the stored procedure result into an entity collection.

David Elizondo | LLBLGen Support Team
jia
User
Posts: 7
Joined: 10-Nov-2010
# Posted on: 15-Nov-2010 19:35:41   

The problem is that the physical table is generated by the code, and the table name varies on the running condition. I shouldn't be able to add it to my LLBLGen project, right?

I wanted to generate the following query to "SELECT" everything but only "GROUP BY" on VISITOR_ID column so the HAVING condition is calculated on VISITOR_ID level. I guess I need a subquery or a temporal physical table (the IN clause):

SELECT [SESSION].[VISITOR_ID] AS [VISITOR_ID], [SESSION].[ID] AS [SESSION_ID], ** Count([EVENT_OCCURRENCE].ID) OVER(PARTITION BY [SESSION].[VISITOR_ID]) AS [MATCHES] ** FROM ( [SESSION] INNER JOIN [EVENT_OCCURRENCE]
ON [SESSION].[ID]=[EVENT_OCCURRENCE].[SESSION_ID])

  WHERE ( ( [EVENT_OCCURRENCE].[EVENT_ID] = 50) 
  AND ( [SESSION].[END] >= '11/01/2010 12:00:00 AM' 
  AND [SESSION].[END] <= '11/01/2010 11:59:59 PM') 
  AND ( [SESSION].[VISITOR_ID] <> 0)
  AND [SESSION].[VISITOR_ID] IN (**SELECT [SESSION].[VISITOR_ID] AS [VISITOR_ID] 
  FROM ( [SESSION]  INNER JOIN [EVENT_OCCURRENCE]  
  ON  [SESSION].[ID]=[EVENT_OCCURRENCE].[SESSION_ID]) 
  WHERE ( ( [EVENT_OCCURRENCE].[EVENT_ID] = 50) 
  AND ( [SESSION].[END] >= '11/01/2010 12:00:00 AM' 
  AND [SESSION].[END] <= '11/01/2010 11:59:59 PM') 
  AND ( [SESSION].[VISITOR_ID] <> 0)) 
  GROUP BY [SESSION].[VISITOR_ID]
  HAVING ( COUNT([EVENT_OCCURRENCE].[ID]) >= 2))**)

This is for SQL Server 2008 R2. SESSION and EVENT_OCCURENCE are both in the LLBLGEN project.

I intend to make the subquery result into a temporal table, then either use the IN clause or JOIN.

Could derived table be used if I use JOIN instead of IN?

daelmo wrote:

jia wrote:

Sorry I didn't make myself clear. It's a physical table created for a temporary purpose.

If it's a physical table created by you, then you can add it to your LLBLGen project so you would be able to use it when constructing LLBLGen queries. Am I right?

If you don't do that, I don't see other option than use your own stored procedure. Then you can project the stored procedure result into an entity collection.

daelmo avatar
daelmo
Support Team
Posts: 8245
Joined: 28-Nov-2005
# Posted on: 16-Nov-2010 07:04:51   

You can reproduce that query with some subqueries using FieldCompareSetPredicate, without temp tables. Do you have problems to reproduce the above query in LLBLGen?

David Elizondo | LLBLGen Support Team
jia
User
Posts: 7
Joined: 10-Nov-2010
# Posted on: 16-Nov-2010 19:27:48   

I don't know how to do that. Can FieldCompareSetPredicate be defined to generate such a complex query?

daelmo wrote:

You can reproduce that query with some subqueries using FieldCompareSetPredicate, without temp tables. Do you have problems to reproduce the above query in LLBLGen?

MTrinder
User
Posts: 1461
Joined: 08-Oct-2008
# Posted on: 16-Nov-2010 22:06:17   

What are you actually trying to achieve with the OVER (PARTITION BY...) section of the query...?

Matt

jia
User
Posts: 7
Joined: 10-Nov-2010
# Posted on: 16-Nov-2010 23:16:33   

Do the count calculation as if GROUP BY by VISITOR_ID. Essentially I want a SQL statement that selects VISITOR_ID, SESSION_ID, COUNT(EVENT_ID) with a filter condition on COUNT that is only grouped on VISITOR level, not on both VISITOR and SESSION. A visitor can have multiple sessions and a session can have multiple event occurrences.

The window function is not a big problem ,as I can hardcode it into generated SQL. My main challenge is on how to generate the subquery, as I don't want to hardcode the IN clause.

If there are other means without using subquery or multiple querys, it would be great too.

Thanks.

MTrinder wrote:

What are you actually trying to achieve with the OVER (PARTITION BY...) section of the query...?

Matt

Walaa avatar
Walaa
Support Team
Posts: 14995
Joined: 21-Aug-2005
# Posted on: 17-Nov-2010 09:56:55   

How many records should the subQuery return? In which magnitude.

One solution I'd take is fetch the resultSet instead of saving them in a temp table, and then use the FieldCompareRangePredicate and pass these values as the range.

Another solution: If the temp table's struture is well known beforehand, then you might want to consider fixing it as a permenant table, and so you can use it in LLBLGen, these will make yourlife simpler afterwards.

And most probably you might need to add an extra column (Token) to differentiate between different resultsets being saved in the table at runtime. And you might consider clearing the specified resultSet once you have finished using them.

jia
User
Posts: 7
Joined: 10-Nov-2010
# Posted on: 17-Nov-2010 18:38:30   

Thanks for all the input. I will give them a try.

Walaa wrote:

How many records should the subQuery return? In which magnitude.

One solution I'd take is fetch the resultSet instead of saving them in a temp table, and then use the FieldCompareRangePredicate and pass these values as the range.

Another solution: If the temp table's struture is well known beforehand, then you might want to consider fixing it as a permenant table, and so you can use it in LLBLGen, these will make yourlife simpler afterwards.

And most probably you might need to add an extra column (Token) to differentiate between different resultsets being saved in the table at runtime. And you might consider clearing the specified resultSet once you have finished using them.