Problem with request

Hi,

I'm using pymssql based on libsysdb5 which come from freedts-common on
debian testing. When I'm running the following request :

SELECT name,option FROM appels

I got an error because option is a keyword and the request can't be
run. I'm trying to put [] or "" and it does not change anything, how
could I run this request?

Second I have a problem with ntext field. I could cast them, I'dll
like to know if there is plan in the future to accept field using
ntext.

Thanks by advance,
Regards
Sébastien
_______________________________________________
FreeTDS mailing list
FreeTDS <at> lists.ibiblio.org
http://lists.ibiblio.org/mailman/listinfo/freetds

Get access to my pictures and more

Hey,

I have created a Netlog profile with my pictures, videos, blogs and events and I want to add you as a friend so
you can see it. You first need to register on Netlog! When you log in, you can create your own profile.

Take a look:
http://en.netlog.com/go/mailurl/-bT0xOTQ2MDU1NDgwJmw9MSZnbT0xMiZ1PSUyRmdvJTJGcmVnaXN0ZXIlMkZpZCUzRC1abkpsWlhSa2MwQnNhWE4wY3k1cFltbGliR2x2TG05eVp3X18lMjZ1aWQlM0QxMTg3OTAyMTM_

Cheers,
nitin

----------------------------------------------------------------
Don't want to receive invitations from your friends anymore?
http://en.netlog.com/go/mailurl/-bT0xOTQ2MDU1NDgwJmw9MiZnbT0xMiZ1PSUyRmdvJTJGbm9tYWlscyUyRmludml0ZSUyRmVtYWlsJTNELVpuSmxaWFJrYzBCc2FYTjBjeTVwWW1saWJHbHZMbTl5WndfXyUyNmNvZGUlM0QwNDUxODAzMw__

Re: Problem with request

2011/7/2 Sébastien Morand <seb.morand <at> gmail.com>:
> Hi,
>
> I'm using pymssql based on libsysdb5 which come from freedts-common on
> debian testing. When I'm running the following request :
>
> SELECT name,option FROM appels
>
> I got an error because option is a keyword and the request can't be
> run. I'm trying to put [] or "" and it does not change anything, how
> could I run this request?
>

usually [] works like

SELECT [name], [option] FROM appels

> Second I have a problem with ntext field. I could cast them, I'dll
> like to know if there is plan in the future to accept field using
> ntext.
>

No plan, should work...
Which problem do you have?

> Thanks by advance,
> Regards
> Sébastien

freddy77

[documentation] using both freetds.conf and odbc.ini parameters

Hello

I have just been through a setup connecting an Oracle database to an MS 
SQL database using FreeTDS. I want to express my thanks for this great 
project.

I also want to point out something that was not so straightforward for 
me reading the otherwise very good documentation.

When retrieving data from the server, I had '?' characters in the place 
of some accented characters. So I needed to set the "client charset" 
parameter, which is only doable in freetds.conf.

Now there is a nice descripiton in "Chapter 5. Advanced Configurations > 
Localization and TDS 7.0" of this "question mark issue". But I was using 
the odbc.ini file for configuration, and this page did not tell me 
whether I can, and if I can, how to use this setting in the odbc.ini, or 
if I cannot, how to get FreeTDS to use this parameter from freetds.conf.

Later I found out that the answer is described in "Chapter 4. Preparing 
ODBC > ODBC-combined configuration". Everything is documented fine, but 
a small hint or a reference to this page from the "Localization and TDS 
7.0" page might come in handy for others as well.

It would also be nice to make it clear at some point in the 
documentation (perhaps in "Chapter 4. Preparing ODBC > Background and 
Terminology") that some parameters can only be set in freetds.conf, 
while others only in odbc.ini. This was not so clear for me either.

Thank you again.

FreeTDS and PHP: empty strings and NVARCHAR

Hi,
yesterday I modified PHP and FreeTDS codes to make them work with empty
strings and nvarchar in stored procedures.

1. The empty_string.patch (against actual cvs of FreeTDS) is like the ct-lib
patch (so datalen==0 is not null).

2. The nvarchar_export.patch defines XSYBNVARCHAR in sybdb.h (to use
with php).

3. The freetds092_with_nvarchar.patch (against php 5.3.6 stable) fixes a
redefinition of type LBYTE to work with actual Freetds cvs and adds support
for type SQLNVARCHAR (to use with mssql_bind function).

The first patch could break the dblib standard so it could remain an unofficial
patch.

The second one shouldn't cause problems. It could be merged in the main
tree.

I hope I have done something useful.

Regards

--

-- 
Mattia

Re: FreeTDS and PHP: empty strings and NVARCHAR

Attachments ;)

--

-- 
Mattia

_______________________________________________
FreeTDS mailing list
FreeTDS <at> lists.ibiblio.org
http://lists.ibiblio.org/mailman/listinfo/freetds

win32 build, ptw32_mcs_lock.{c,obj} in Nmakefile

Hi all,

Doing a build of the latest 0.91RC under win32 using
the Nmakefile I get failures when it's trying to build
the ptw32_MCS_lock.c.

But that file is #include'd (from src/tds/win_mutex.c) so no
compilation nor linking should be performed for it, if I've
understood things correctly.

This simple patch fixed the issue:

diff -u -r1.10.2.1 Nmakefile
--- Nmakefile   29 Jun 2011 13:09:58 -0000      1.10.2.1
+++ Nmakefile   5 Jul 2011 22:12:13 -0000
 <at>  <at>  -89,7 +89,6  <at>  <at> 
                $(TDS_DIR)\mem.c \
                $(TDS_DIR)\net.c \
                $(TDS_DIR)\numeric.c \
-               $(TDS_DIR)\ptw32_MCS_lock.c \
                $(TDS_DIR)\query.c \
                $(TDS_DIR)\read.c \
                $(TDS_DIR)\sspi.c \
 <at>  <at>  -120,7 +119,6  <at>  <at> 
                $(TDS_OUT)\mem.obj \
                $(TDS_OUT)\net.obj \
                $(TDS_OUT)\numeric.obj \
-               $(TDS_OUT)\ptw32_MCS_lock.obj \
                $(TDS_OUT)\query.obj \
                $(TDS_OUT)\read.obj \

Re: win32 build, ptw32_mcs_lock.{c,obj} in Nmakefile

2011/7/6 Ramiro Morales <cramm0 <at> gmail.com>:
> Hi all,
>
> Doing a build of the latest 0.91RC under win32 using
> the Nmakefile I get failures when it's trying to build
> the ptw32_MCS_lock.c.
>
> But that file is #include'd (from src/tds/win_mutex.c) so no
> compilation nor linking should be performed for it, if I've
> understood things correctly.
>
> This simple patch fixed the issue:
>
> diff -u -r1.10.2.1 Nmakefile
> --- Nmakefile   29 Jun 2011 13:09:58 -0000      1.10.2.1
> +++ Nmakefile   5 Jul 2011 22:12:13 -0000
>  <at>  <at>  -89,7 +89,6  <at>  <at> 
>                $(TDS_DIR)\mem.c \
>                $(TDS_DIR)\net.c \
>                $(TDS_DIR)\numeric.c \
> -               $(TDS_DIR)\ptw32_MCS_lock.c \
>                $(TDS_DIR)\query.c \
>                $(TDS_DIR)\read.c \
>                $(TDS_DIR)\sspi.c \
>  <at>  <at>  -120,7 +119,6  <at>  <at> 
>                $(TDS_OUT)\mem.obj \
>                $(TDS_OUT)\net.obj \
>                $(TDS_OUT)\numeric.obj \
> -               $(TDS_OUT)\ptw32_MCS_lock.obj \
>                $(TDS_OUT)\query.obj \

Re: FreeTDS and PHP: empty strings and NVARCHAR

2011/7/4 Mattia <mattia <at> p2pforum.it>:
> Hi,
> yesterday I modified PHP and FreeTDS codes to make them work with empty
> strings and nvarchar in stored procedures.
>
> 1. The empty_string.patch (against actual cvs of FreeTDS) is like the ct-lib
> patch (so datalen==0 is not null).
>

Yes, this breaks dblib compatibility. All documentation report datalen
== 0 as NULL input.

> 2. The nvarchar_export.patch defines XSYBNVARCHAR in sybdb.h (to use
> with php).
>

?? this should be not necessary, our dblib should convert to
SYBVARCHAR and PHP should be happy with given varchar... If this is
not true we should fix FreeTDS dblib instead.

> 3. The freetds092_with_nvarchar.patch (against php 5.3.6 stable) fixes a
> redefinition of type LBYTE to work with actual Freetds cvs and adds support
> for type SQLNVARCHAR (to use with mssql_bind function).
>

This is a PHP patch, I think you should split patch and send them.

> The first patch could break the dblib standard so it could remain an unofficial
> patch.
>

Re: FreeTDS and PHP: empty strings and NVARCHAR

On Jul 7, 2011, at 4:50 AM, Frediano Ziglio wrote:

>> 2. The nvarchar_export.patch defines XSYBNVARCHAR in sybdb.h (to use
>> with php).
>> 
> 
> ?? this should be not necessary, our dblib should convert to
> SYBVARCHAR and PHP should be happy with given varchar... If this is
> not true we should fix FreeTDS dblib instead.

Agreed, it should not, I use dblib just fine with the given varchar and it tested with all "chary" data types.

 - Ken