Re: SQLDriverConnect() gives "user breakpoint" and no more help

OK. ODBC is really good once you get over the hurdles.

My first check would have been the SQL_NTS change...

- Tim


"Jo" <JoJoTwilligo@xxxxxxxxxxx> wrote in message
news:1116304977.098593.266560@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
>
> Tim wrote:
>> When the program breaks into assembler, have you tried pressing F5 to
>
>> continue execution to see what results? Does the Debug output window
> have
>
> No, because usually at that point the exception (or whatever it is)
> is thrown again, and I don't get anywhere.
>
>> any helpful output? It may not hurt to isntall debug symbols that way
> you
>
> It gave me something, but I don't know if I'd call it helpful:
> Invalid Address specified to RtlFreeHeap( 00D80000, 00D84018 ). I
> haven't been able to figure out how that could help me.
>
>> will know what internal windows functions you are at and where you
> head as
>> you step forwards.
>
> I don't know what you mean by debug symbols? Do you mean watches?
>
> It's accademic at this point, since I've solved the problem by
> dumping direct use of the SDK's ODBC API all together. It's way too
> hairy a library to work with, so I just went and found another API.
> Thanks anyway.
>
>
>>
>> In the mean time:
>>
>> Instead of
>>
>> nReturn = SQLDriverConnect(m_sqlconnection, m_hWnd, (SQLCHAR *)"",
>> ==> 0,
>> lpszStringOut, 1024, &nOutSize, SQL_DRIVER_PROMPT);
>>
>> using Zero on the second line above, use SQL_NTS - this indicates
> that the
>> input parameter preceeding is an SQL Null Terminated String IE.
>>
>> nReturn = SQLDriverConnect(m_sqlconnection, m_hWnd, (SQLCHAR *)"",
>> SQL_NTS,
>> lpszStringOut, 1024, &nOutSize, SQL_DRIVER_PROMPT);
>>
>>
>> When you set an option for something like an ODBC version compliance
> request
>> (IE you ask for V3), you have to know well that you can handle the
> likely
>> outcomes. IE ask for the minimum compliance level that you need and
> that the
>> driver you are sure is installed is guaranteed to support.
>>
>> Just because the driver has a File Version of 3.x does not mean for a
> moment
>> that it is capable of ODBC compliance at level 3 - this is a
> different
>> vocabulary of verbs that can be used as compared to level 1.
>>
>> I suggest you replace your Asserts with if statements and progress
> only on
>> success / success with info. Write a stock function to dump out any
> info
>> responses you get so that you can check off the messages the driver
> wants
>> you to know about. Also write a stock error message reporting
> function to
>> dump out error messages at least while you are coding to ensure you
> KNOW
>> what the errors that you are dealing with are.
>>
>> Its been some time since I have used ODBC at this level...
>>
>> - Tim
>>
>>
>>
>>
>>
>> "Jo" <JoJoTwilligo@xxxxxxxxxxx> wrote in message
>> news:1116295950.705410.37190@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
>> >
>> > Tim wrote:
>> >> Where does it assert?
>> >
>> > It doesn't assert. It just throws me into the disassembler during
>> > the SQLDriverConnect() call, somewhere in NTDLL. I try going back
>> > through the call stack, but I never get out of the disassember.
>> >
>> >> What are the lines of code preceeding the assert?
>> >
>> > There aren't any. You are looking at the beginning of the
> method.
>> > The only call before that is to the constructor, and there's
> nothing
>> > that could affect it there.
>> >
>> >>
>> >> Do you know if the driver supports the version of ODBC you are
>> > requesting?
>> >
>> > I'm not sure what you mean. As you can see, It's ODBC 3.x that
> I'm
>> > using, but the lower-lever driver is MyODBC 3.51-2.
>> >
>> >>
>> >> While you have asserts, you do not have any error checking. If you
>> > are
>> >> getting success with info, what is the info? This code wiould
> gladly
>> > break
>> >> in production...
>> >>
>> >>
>> >> - Tim
>> >>
>> >>
>> >> "Jo" <JoJoTwilligo@xxxxxxxxxxx> wrote in message
>> >> news:1116258065.788258.70550@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
>> >> > I'm having a hard time getting this SDK's ODBC library to work
> for
>> > me.
>> >> > I've been following the guide in the MSDN, but whenever I call
>> >> > SQLDriverConnect(), I can select the machine source (in this
> case,
>> > it
>> >> > uses the MySQL Connector/ODBC) then ok the login screen, and get
> a
>> >> > "user breakpoint" before the function can return. That's not
> much
>> > help,
>> >> > and I'm not aware of any exceptions I can trap. Here's my code:
>> >> >
>> >> > SQLHDBC m_sqlconnection;
>> >> > SQLHENV m_sqlenv;
>> >> >
>> >> > ...
>> >> >
>> >> > SQLRETURN nReturn = SQLAllocHandle(SQL_HANDLE_ENV,
> SQL_NULL_HANDLE,
>> >> > &m_sqlenv);
>> >> > assert(nReturn == SQL_SUCCESS || nReturn ==
> SQL_SUCCESS_WITH_INFO);
>> >> >
>> >> > nReturn = SQLSetEnvAttr(m_sqlenv, SQL_ATTR_ODBC_VERSION,
>> >> > (SQLPOINTER)SQL_OV_ODBC3, 0);
>> >> > assert(nReturn == SQL_SUCCESS || nReturn ==
> SQL_SUCCESS_WITH_INFO);
>> >> >
>> >> > nReturn = SQLAllocHandle(SQL_HANDLE_DBC, m_sqlenv,
>> > &m_sqlconnection);
>> >> > assert(nReturn == SQL_SUCCESS || nReturn ==
> SQL_SUCCESS_WITH_INFO);
>> >> >
>> >> > SQLCHAR lpszStringOut[1024];
>> >> > SQLSMALLINT nOutSize;
>> >> > nReturn = SQLDriverConnect(m_sqlconnection, m_hWnd, (SQLCHAR
> *)"",
>> > 0,
>> >> > lpszStringOut, 1024, &nOutSize, SQL_DRIVER_PROMPT);
>> >> >
>> >> > Did I forget anything?
>> >> >
>> >
>


.

Relevant Pages