Hello,

I am using LLBL 1.0.2005.1 w/ Self Servicing, two class, against SQL 2005 using C# template set for SqlServer.

I have tracing for SqlServeDQE at 4.

When my code runs the following:

Debug.Print("************************");

FilterRecordCount = auditCollection1.GetDbCount(_filter);

Debug.Print("************************");

I get the following DQE Trace messages. Why two selects? I understand the 2nd one, just not the first one. I can see where the 1st query is used as a subselect of the 2nd query so I assume a method is being called to generate the first, its traced, and then the 2nd gets traced. My question is, if thats the case, how do I tell which queryies are actually being sent to the SQL server for execution vs. just built as strings in LLBL. I would like to only trace the SQL being sent for execution as I am workign on removing any duplicate queiries/etc. in my code and these "duplicates" are confusing.

It would be nice if where it says "Query: " it would say "Query (Executed): " if it was actually sent for execution or if not that, if a seperate trace message was for the executed lines.

Method Enter: CreateRowCountDQ Method Enter: CreateSelectDQ Method Enter: CreateSelectDQ Generated Sql query: Query: SELECT [Administration].[Audit].[OccuredAt], [Administration].[Audit].[Operation], [Administration].[Audit].[TableName], [Administration].[Audit].[RowKeyValue], [Administration].[Audit].[PerformedBy], [Administration].[Audit].[FieldName], [Administration].[Audit].[OldValue], [Administration].[Audit].[NewValue], [Administration].[Audit].[AuditID] AS [AuditId] FROM [Administration].[Audit] WHERE ( [Administration].[Audit].[OccuredAt] >= @OccuredAt1 AND [Administration].[Audit].[OccuredAt] <= @OccuredAt2 AND [Administration].[Audit].[PerformedBy] = @PerformedBy3) Parameter: @OccuredAt1 : DateTime. Length: 0. Precision: 0. Scale: 0. Direction: Input. Value: 5/7/2006 1:16:34 PM. Parameter: @OccuredAt2 : DateTime. Length: 0. Precision: 0. Scale: 0. Direction: Input. Value: 6/7/2006 12:00:00 AM. Parameter: @PerformedBy3 : AnsiString. Length: 50. Precision: 0. Scale: 0. Direction: Input. Value: Domain\username. Method Exit: CreateSelectDQ Generated Sql query: Query: SELECT COUNT(*) AS NumberOfRows FROM (SELECT [Administration].[Audit].[OccuredAt], [Administration].[Audit].[Operation], [Administration].[Audit].[TableName], [Administration].[Audit].[RowKeyValue], [Administration].[Audit].[PerformedBy], [Administration].[Audit].[FieldName], [Administration].[Audit].[OldValue], [Administration].[Audit].[NewValue], [Administration].[Audit].[AuditID] AS [AuditId] FROM [Administration].[Audit] WHERE ( [Administration].[Audit].[OccuredAt] >= @OccuredAt1 AND [Administration].[Audit].[OccuredAt] <= @OccuredAt2 AND [Administration].[Audit].[PerformedBy] = @PerformedBy3)) TmpResult Parameter: @OccuredAt1 : DateTime. Length: 0. Precision: 0. Scale: 0. Direction: Input. Value: 5/7/2006 1:16:34 PM. Parameter: @OccuredAt2 : DateTime. Length: 0. Precision: 0. Scale: 0. Direction: Input. Value: 6/7/2006 12:00:00 AM. Parameter: @PerformedBy3 : AnsiString. Length: 50. Precision: 0. Scale: 0. Direction: Input. Value: Domain\username. Method Exit: CreateRowCountDQ

You may check the SQL profiler for the executed queries.

The thing is that the DQE tracing is done by the DQE, so it simply traces what it's told to do. If it's told to produce a query it logs that query, it doesn't know if that query is actually a subquery, at least not at that point.

To see when which query is used, you should enable besides DQE tracing the ORMPersistenceExecution tracing.

Though I fully admit it could be done better. As the code is already in place but not used that well, I'll make sure in V2 the ORMPersistenceExecution tracing alone will log the query as it has been executed at runtime.