David,

I downloaded the latest build ["September 17th, 2012"]. Are there ReleaseNotes? or mostly the same... just minor bug fixes..

Ron

The build with your change hasn't been released yet. Will be this week. You can subscribe to the RSS feed which will notify you when a new build is released: http://www.llblgen.com/Pages/RssDownloads.aspx

Changes are in the changelog: http://www.llblgen.com/Pages/ChangeLogBrowser.aspx

Frans,

DataAccessAdapter queries are not logged... e.g. GetUTCDate() below isn't logged.

public class DataAccessAdapter : DataAccessAdapterBase
{
    protected DataAccessAdapter()
        : base(PersistenceInfoProviderSingleton.GetInstance())
    {
    }
    protected override DynamicQueryEngineBase CreateDynamicQueryEngine()
    {
        return new DynamicQueryEngine();
    }

void Test () { return (T)ExecuteScalarQuery(new RetrievalQuery(GetActiveConnection(),new SqlCommand("select GetUTCDate()"))); }

Ron

Fixed. Executing a scalar walks a slightly different code path (as the execution of the query internal is different) and it therefore misses the trace call. Fix is in the attached dll.

(btw 'Test' fails to compile )

Apparently, the query is never logged if the query fails. This means the log doesn't contain the query anytime the query fails - this defeats the whole purpose of having the query logged. It seems as though the query is logged only after it is executed as opposed to before its execution. If this is the case, that's a major limitation. This means anytime there is a failed query, it is unknown what query failed.

Below is an example of the log w/o query - all I get is the error/trace.

*** ERROR: An exception was caught during the execution of an action query: The INSERT statement conflicted with the FOREIGN KEY constraint "FK_ContactIdentification_Type_MB". The conflict occurred in database "Test2_11", table "dbo.Type", column 'TypeID'. The statement has been terminated.. Check InnerException, QueryExecuted and Parameters of this exception to examine the cause of this exception. The INSERT statement conflicted with the FOREIGN KEY constraint "FK_ContactIdentification_Type_MB". The conflict occurred in database "Test2_11", table "dbo.Type", column 'TypeID'. The statement has been terminated. 11/2/2012 5:59:02 PM|th#9256|General | at SD.LLBLGen.Pro.ORMSupportClasses.ActionQuery.Execute() at SD.LLBLGen.Pro.ORMSupportClasses.BatchActionQuery.Execute() at SD.LLBLGen.Pro.ORMSupportClasses.DaoBase.ExecuteActionQuery(IActionQuery queryToExecute, ITransaction containingTransaction) at SD.LLBLGen.Pro.ORMSupportClasses.DaoBase.AddNew(IEntityFields fields, ITransaction containingTransaction) at SD.LLBLGen.Pro.ORMSupportClasses.EntityBase.InsertEntity() at SD.LLBLGen.Pro.ORMSupportClasses.EntityBase.CallInsertEntity() at SD.LLBLGen.Pro.ORMSupportClasses.DaoBase.PersistQueue(List`1 queueToPersist, Boolean insertActions, ITransaction transactionToUse, Int32& totalAmountSaved) at SD.LLBLGen.Pro.ORMSupportClasses.EntityBase.Save(IPredicate updateRestriction, Boolean recurse) at SD.LLBLGen.Pro.ORMSupportClasses.EntityBase.Save()

Ron

The trace is indeed after the query is executed. The reason is that it logs only the queries which were executed correctly. If a query causes an exception, the query is embedded into the exception.

So you log the exception but you should also log the 'QueryExecuted' property contents, which contains the query + parameters which was causing the exception.

The reason this is done this way is that the tracer doesn't log the exception, so if you log the query with tracer X and the exception somewhere else, it's hard to tie them together. As the exception already contains the faulty query (and entity!), this is not an issue, as you can obtain all information you need for your log of the exception from the exception itself

Got it - thank you.