[unixODBC-support] Critical issues Please Help

Wajid Baig wabmca at gmail.com
Tue Oct 16 23:42:34 BST 2012


Hi,

The issue I am facing is

My defination of SQLColDescribe or SQLColAttribute is not called because

*Reason I think is*
*As you can see in below gdb output (See Bold text side heading "gdb
output"), func at 6 and is not defined. In sql.h 6 and 8 are
SQLCOLATTRIBUTE and SQLDESCIBECOL respectively(see Bold text with side
heading "sql.h") .*
**
*SQLDESCIBECOL is defined at 19 (See Bold text side heading "gdb output").
But it is not called*
*when I gdb and gave breakpoint.*
**
*Driver which I compiled listed these functions as defined (See Bold text
side heading "nm output")*
**
*Attention: I started development using template in Drivers directory with
2.2.12 then compiled it with 2.2.14. Now I dont see Column headers in isql
header. I using g++ on rhel to compile the driver. *
**
*Questioin: Where should I make the change in my driver so that these func
get defined and called. Why is the array index not getting populated for
*statement -> connection -> functions[6].func and *statement -> connection
-> functions[8].func*

#if (ODBCVER >= 0x0300)
#define SQL_API_SQLCLOSECURSOR       1003
#define SQL_API_SQLCOLATTRIBUTE         6
#endif
#define SQL_API_SQLDESCRIBECOL          8

*gdb output*
(gdb) p *statement -> connection -> functions[6].func
Cannot access memory at address 0x0
(gdb) p *statement -> connection -> functions[8].func
Cannot access memory at address 0x0

For me SQLDescribeCol is defined at
(gdb) p *statement -> connection -> functions[19].func
$13 = {SQLRETURN ()} 0x7ffff18a8c7c
     <SQLDescribeCol(SQLHSTMT, SQLUSMALLINT, SQLCHAR*, SQLSMALLINT,
SQLSMALLINT*, SQLSMALLINT*, SQLULEN*, SQLSMALLINT*, SQLSMALLINT*)>
*sql.h*
**
In sql.h 6 and 8 are SQLCOLATTRIBUTE and SQLDESCIBECOL respectively.

#if (ODBCVER >= 0x0300)
#define SQL_API_SQLCLOSECURSOR       1003
#define SQL_API_SQLCOLATTRIBUTE         6
#endif
#define SQL_API_SQLDESCRIBECOL          8

*nm output*
**
# nm libMyDBODBC.so  | grep SQLDesc
0000000000012c7c T SQLDescribeCol
00000000000132af t _GLOBAL__I_SQLDescribeCol.c
# nm libMyDBODBC.so  | grep SQLColAt
0000000000021d9a t _GLOBAL__I_SQLColAttribute.c
000000000000a467 t _GLOBAL__I_SQLColAttributes.c
00000000000210e8 T _Z15SQLColAttributePvttS_sPsS_
0000000000009914 T _Z16SQLColAttributesPvttS_sPsS_



On Fri, Oct 12, 2012 at 3:31 PM, Wajid Baig <wabmca at gmail.com> wrote:

> Hi Martin,
>
>   Thanks you so very much. My Apologies I did not see atleast man on
> setlocale.
>
>   I beg your pardon. Thanks to respond so very quickly. Love you.
>
>   I am concerned about my intutiveness now :(.
>
> Happy Week End.
>
> Ahmed
>
>  On Fri, Oct 12, 2012 at 2:22 PM, Martin J. Evans <bohica at ntlworld.com>wrote:
>
>> On 12/10/12 09:04, Wajid Baig wrote:
>>
>>> Hi Nick,
>>>
>>>    Regarding local my question
>>>   in -lx what should be x. Is it a number or string. Because when I give
>>> command locale result is
>>>
>>> LANG=en_US.UTF-8
>>> LC_CTYPE="en_US.UTF-8"
>>> LC_NUMERIC="en_US.UTF-8"
>>> LC_TIME="en_US.UTF-8"
>>> LC_COLLATE="en_US.UTF-8"
>>> LC_MONETARY="en_US.UTF-8"
>>> LC_MESSAGES="en_US.UTF-8"
>>> LC_PAPER="en_US.UTF-8"
>>> LC_NAME="en_US.UTF-8"
>>> LC_ADDRESS="en_US.UTF-8"
>>> LC_TELEPHONE="en_US.UTF-8"
>>> LC_MEASUREMENT="en_US.UTF-8"
>>> LC_IDENTIFICATION="en_US.UTF-**8"
>>> LC_ALL=
>>>
>>
>> I've not been following this properly but the argument to setlocale can
>> be found from the man 3 page for setlocale:
>>
>>  man 3 setlocale
>>
>> char *setlocale(int category, const char *locale);
>>
>> so it is a char * and so it is a string.
>>
>> Martin
>>
>>  On Fri, Oct 12, 2012 at 3:40 AM, Nick Gorham <nick at lurcher.org <mailto:
>>> nick at lurcher.org>> wrote:
>>>
>>>     On 11/10/12 22:58, Wajid Baig wrote:
>>>
>>>>
>>>>     Hi Nick,
>>>>
>>>>       I am facing very critical issues. I am using 2.2.14.
>>>>     Issue 1:
>>>>
>>>>     isql utility is not printing Column  names in header. I see header
>>>> box as empty.
>>>>     *When I debug, giving breakpoints at functions SQLColAttribute and
>>>> SQLColAttribute gdb is not stoping. No call is made to these functions. I
>>>> am facing this issue both without using -c and -d and with using this
>>>> parameters.*
>>>>     *Can you tell me what could be the issue?*
>>>>
>>>
>>>     Look at the code, I think I used SQLDescribeCol to get the name. But
>>> anyway, it will be the driver thats not returning them, not isql. You dont
>>> say what driver you are using.
>>>
>>>
>>>     Issue 2:
>>>>
>>>>      Locale:
>>>>      What should be x when using "-lx" parameter in isql utility?
>>>>
>>>>
>>>>     Again, the code is your friend. The arg to the -l option is passed
>>> to
>>>
>>>     setlocale( LC_ALL, arg );
>>>
>>>     --
>>>     Nick
>>>
>>>     ______________________________**_________________
>>>     unixODBC-support mailing list
>>>     unixODBC-support at mailman.**unixodbc.org<unixODBC-support at mailman.unixodbc.org><mailto:
>>> unixODBC-support@**mailman.unixodbc.org<unixODBC-support at mailman.unixodbc.org>>
>>>
>>>
>>>     http://mailman.unixodbc.org/**mailman/listinfo/unixodbc-**support<http://mailman.unixodbc.org/mailman/listinfo/unixodbc-support>
>>>
>>>
>>>
>>>
>>> --
>>>
>>> Sincerely
>>> Baig
>>> 09176627037
>>>
>>>
>>> ______________________________**_________________
>>> unixODBC-support mailing list
>>> unixODBC-support at mailman.**unixodbc.org<unixODBC-support at mailman.unixodbc.org>
>>> http://mailman.unixodbc.org/**mailman/listinfo/unixodbc-**support<http://mailman.unixodbc.org/mailman/listinfo/unixodbc-support>
>>>
>>>
>> ______________________________**_________________
>> unixODBC-support mailing list
>> unixODBC-support at mailman.**unixodbc.org<unixODBC-support at mailman.unixodbc.org>
>> http://mailman.unixodbc.org/**mailman/listinfo/unixodbc-**support<http://mailman.unixodbc.org/mailman/listinfo/unixodbc-support>
>>
>
>
>
> --
>
> Sincerely
> Baig
> 09176627037
>



-- 

Sincerely
Baig
09176627037
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.unixodbc.org/pipermail/unixodbc-support/attachments/20121017/fe321906/attachment.html>


More information about the unixODBC-support mailing list