ExecuteScalarQuery is not wiring the current adapters connection to the query, resulting in the error "No Connection present. Cannot execute command".

I think it should wire it up like the ExecuteActionQuery.

Hi Brian.

• Please post the relevant code.
• Are the connectionString present at config file?
• Does this happen only with ExecuteScalarQuery or at Fetches of entitycollections as well?
• Also post the LLBLGenPro version and runtime libraries version (http://www.llblgen.com/tinyforum/Messages.aspx?ThreadID=7717).

• Version is 2.5 Final, runtime versions is 2.5.08.0122
• Yes the connection string is present
• Only happens when using ExecuteScalarQuery

--This code works public string PONextNumber1(int poid) { using (DataAccessAdapter adapter = new DataAccessAdapter()) { DataTable dt = RetrievalProcedures.GetPONextNumber(poid, adapter); return dt.Rows.Count == 0 ? string.Empty : dt.Rows[0][0].ToString(); } }

--This code does not public string PONextNumber2(int poid) { using (DataAccessAdapter adapter = new DataAccessAdapter()) { RetrievalQuery retrievalQuery = RetrievalProcedures.GetGetPONextNumberCallAsQuery(poid); return adapter.ExecuteScalarQuery(retrievalQuery).ToString(); } }

Using Lutz, you can see that the ExecuteActionQuery checks the connection of the query, and if not set, it assigns it the _activeConnection. The ExecuteScalarQuery does not check/set the query connection and I am not seeing a way to set the active connection myself before calling.

Brian

As far as I know RetrievalProcedures return a resultSet (dataTable or dataSet) While ExecuteScalarQuery() should be used with scalar queries, which return a single value not a resultSet.

So if GetGetPONextNumberCallAsQuery is not actually a retrieval query then you should use the Catalog Explorer in the Designer to change its return type (no. of resultSets returned to 0).

Otherwise I might be missing something obvious but, but I see no point in using ExecuteScalarQuery() to fetch a retrieval SP.

ExecuteScalarQuery is used to return the value from the first row, first column of a resultset (the same as DataAccessAdapter.GetScalar and IDbCommand.ExecuteScalar)

This particular procedure returns 1 row and 1 column, fitting nicely into the ExecuteScalarQuery which is what I want. The extra over head of creating and populating a DataTable is unnecessary.

The way the code looks in Lutz the ExecuteScalarQuery will never assign its active connection to the IRetrievalQuery passed in, this is the issue.

Regards

Brian

Indeed a bug. The RetrievalQuery you create is meant to be passed to for example FetchDataReader, or FetchProjection. There, the connection is wired, hence we never noticed it.

Will fix it.

See attached build for the fixed code.

Quick turnaround as usual, thanks!