OK, we can switch on generated sql query debug output and that's fine. However, it would be very nice to have a ready-to-execute sql statement handy.

I mean properly formated so one could copy&paste to sql server manager (or any other sql statement executing capable tool). And I am talking mostly about parameters output, since query formatting is almost there (Query: word should be stripped or moved up one line)

So instead of:

Parameter: @IsPublic1 : Boolean. Length: 0. Precision: 0. Scale: 0. Direction: Input. Value: True.

we might have:

DECLARE @IsPublic1 bit
SET @IsPublic1 = 1

Yes, this would be nice. I have a helper application that does this reformatting, but built-in would be nicer.

problem is that the query tracing output is performed in generic code, while the parameter output as you describe it, would require db specific text...

Otis wrote:

problem is that the query tracing output is performed in generic code, while the parameter output as you describe it, would require db specific text...

Ehm, virtual methods? :-)

mihies wrote:

Otis wrote:

problem is that the query tracing output is performed in generic code, while the parameter output as you describe it, would require db specific text...

Ehm, virtual methods? :-)

Heh oh? What are they?

Ok, but, I then also have to implement db specific parameter objects or something. Pretty overkill because where to override the virtual methods?

Can't you just add a (virtual ) method to (i.e.) DynamicQueryEngine that accepts a (db-independent) parameter and outputs the text I mentioned?

mihies wrote:

Can't you just add a (virtual ) method to (i.e.) DynamicQueryEngine that accepts a (db-independent) parameter and outputs the text I mentioned?

That would be possible if the code in which the tracing takes place has a reference to the DQE, but that's not the case.

OK, to sum it up. The feature is very handy and if you don't implement it I'll do it in a way or another So, shall I start coding? (note that I am not pushing anything-ok, a little -just need to make a decision)

Well, the tracing is done inside the Query class. (in the override of ToString())

The query object doesn't have a reference from a DQE, nor does the caller of the ToString() method (TraceHelper.WriteIf etc.) know the DQE. THe problem is that the call to the tracehelper is done from the DQE, however the tracehelper is generic code. So the DQE has to be passed into the query when the tracehelper method is called. But, that is not what you want, as the DQE has no business inside the query object. So you've to make the TEST to see if you have to call the tracehelper around the call to the tracehelper (testing the flags). Error prone.

If anybody is interested I crafted some code. Find it here: http://cs.rthand.com/blogs/blog_with_righthand/archive/2006/09/14/Implementing-more-useful-tracing-for-LLBLGenPro-2.0x.aspx

Thanks!

We'll soon have the external resource page up (it gets bumped downwards in the queue but I really will see to it that it gets added soon) which this would be a good addition to Drop me a line when the external resource page is up so I get your resources added

mihies wrote:

If anybody is interested I crafted some code. Find it here: http://cs.rthand.com/blogs/blog_with_righthand/archive/2006/09/14/Implementing-more-useful-tracing-for-LLBLGenPro-2.0x.aspx

It works super. Thank you Patrick