What's wrong with this block of code?

Writing an ODBC application in C++ using the Win32 API.

The system sets the environment handles and connects to the DSN successfully.  However, the call to SQLExecDirect() is returning an error code, but the error handling block's call to SQLGetDiagRec() is not giving me any information about what the error is (A dialog with no information pops up).  I have included the relevant code block.  My main concern is the error handling block.  If I can at least figure out what the error is, I can troubleshoot the SQLExecDirect() problem myself.

Thanks!
retCode=SQLExecDirect(hStmt, (SQLCHAR*)spQuery, SQL_NTS);	//Execute discovery query
if(retCode!=SQL_SUCCESS && retCode!=SQL_SUCCESS_WITH_INFO)
{
	SQLCHAR sqlState[6]="";
	SQLINTEGER nativeError=NULL;
	SQLCHAR errMsg[SQL_MAX_MESSAGE_LENGTH]="";
	int i = 1;
	char message[512]="";
	SQLGetDiagRec(SQL_HANDLE_DBC, hDbc, i, sqlState, &nativeError, errMsg, sizeof(errMsg), NULL);
	sprintf(message, "Diag: %d, SQLSTATE: %s NativeError: %d ErrMsg: %s", i++, sqlState, nativeError, errMsg);
	MessageBox(NULL, message, "Err", MB_OK);
}

Open in new window

LVL 14
cuziyqAsked:
Who is Participating?
 
cuziyqConnect With a Mentor Author Commented:
One more thing for those who are curious . . . the error handling block does not work because the call to SQLGetDiagRec() was passing in the connection handle.  It worked before because when I deliberately misspelled the password or the DSN, it was a connection issue.  However, when I messed up the query and called SQLGetDiagRec(), it was no longer a connection issue.  SQL_HANDLE_DBC is inappropriate for diagnosing a statement error.  Passing in the statement handle (SQL_HANDLE_STMT) is necessary to get error information about a failed query.  When I chaged it, I get a full, plain English text error message in all its glory.
0
 
evilrixSenior Software Engineer (Avast)Commented:
When you say "no information" can you be more specific please? An empty dialog or text without the error details filled in?
0
 
grg99Commented:
Try initializing the error info fields with "foo", 999, and "goo".  Perhaps the get diag call is failing.  Does that function perhaps return its own error code that you could check?
0
Free Tool: Path Explorer

An intuitive utility to help find the CSS path to UI elements on a webpage. These paths are used frequently in a variety of front-end development and QA automation tasks.

One of a set of tools we're offering as a way of saying thank you for being a part of the community.

 
cuziyqAuthor Commented:
No information.  In the if{} block, I have sqlState, nativeError, and errMsg all intialized to empty strings.  The call to SQLGetDiagRec() is supposed to fill those variables with the relevant information.  Then a message box comes up displaying the values of those variables.

The dialog box is coming up with nothing.  It says "Diag: 1, SQLSTATE: , NativeError: , ErrMsg: " with an OK button.  Setting a breakpoint at the MessageBox() line confirms that all the strings are still empty.

The block does work correctly in other contexts.  If I misspell the password or the DSN name, for example, the error pops up telling me exactly what is wrong.  It all runs through the same function.  This is the only case where I get nothing, and I don't know why.
0
 
ikeworkCommented:
you assume there was an error, but you didnt check the return value of SQLGetDiagRec.

adapted from http://msdn2.microsoft.com/en-us/library/ms711727.aspx:


SQLRETURN rc2;
i = 1;
while ((rc2 = SQLGetDiagRec(SQL_HANDLE_DBC, hDbc, i, sqlState, 
                            &nativeError, errMsg, sizeof(errMsg), NULL)) 
                            != SQL_NO_DATA) 
{
    sprintf(message, "Diag: %d, SQLSTATE: %s NativeError: %d ErrMsg: %s", 
            i++, sqlState, nativeError, errMsg);
    MessageBox(NULL, message, "Err", MB_OK);
    ++i;
}
 
 
// ike

Open in new window

0
 
cuziyqAuthor Commented:
Well, folks, I figured out the source of my error.  My Stored Procedure has an ORDER BY clause on a SELECT COUNT(*) query, which is illegal.  I fixed the stored procedure and it now works fine.  I am sure I will revisit the issue later when I have some other stored procedure that doesn't work properly.
0
 
evilrixSenior Software Engineer (Avast)Commented:
You should be able to order by count as a named field...

select count(*) as cnt from sometable group by somefield order by cnt;
0
 
ikeworkCommented:
>> You should be able to order by count as a named field...

some rdbms allow it .. some not .. mostly "order by count(*)"  works
0
 
modus_operandiCommented:
Closed, 500 points refunded.
modus_operandi
EE Moderator
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.