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
|
Hi Guys, With the native LINQ to SQL stuff provided by Microsoft one can do a from where select statement and then drop a break point in after it and view the sql code for that statement by inspecting the var for that statement. For Example: putting a break point after this line of code and then
inspecting the BIQuery variable reveals the SQL code that would be pushed to the
DB, var BIQuery = <statement>; Is there a similar way to do this for LightSpeed? Thanks Again for your help, Josh |
|
|
There are a couple of ways you can do this. 1. You can view it in the VS debugger (as you do with LINQ to SQL) by inspecting the Query object. However, because a Query is abstract of a particular database, this only works once the Query has been handed off to an IUnitOfWork. So you can use this to view the SQL if you put the breakpoint (or perform the inspection) after the Find statement, but not before. 2. We also provide a VS debug visualiser so you can inspect the SQL in a nice big window, properly laid out, rather than a tooltip. Click the magnifying glass icon when inspecting a Query object. You'll need to copy Mindscape.LightSpeed.DebuggerVisualizer.dll to [VS directory]\Common7\Packages\Debugger\Visualizers or My Documents\Visual Studio 2008\Visualizers for this to work. Also, the same limitation applies on only being able to use it after the Query has been passed to an IUnitOfWork. 3. You can use LightSpeedContext.Logger to capture the SQL. For example, set unitOfWork.Context.Logger = new TraceLogger() to dump the SQL to the debug Output window. |
|
|
Oh -- and options 1 and 2 will only work if you're using the core API, because the LINQ provider doesn't provide access to the Query object. Option 3 will still work with LINQ. |
|
|
Ivan, your a star! Thanks again for your help! |
|