Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1aUwUl-0007yp-Oy for pgsql-odbc@arkaria.postgresql.org; Sun, 14 Feb 2016 13:13:48 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84) (envelope-from ) id 1aUwUk-0002Ke-7F for pgsql-odbc@arkaria.postgresql.org; Sun, 14 Feb 2016 13:13:46 +0000 Received: from makus.postgresql.org ([2001:4800:1501:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84) (envelope-from ) id 1aUwUi-0002KD-3s; Sun, 14 Feb 2016 13:13:44 +0000 Received: from mailuogwdur.emc.com ([128.221.224.79]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84) (envelope-from ) id 1aUwUZ-0006Yt-MA; Sun, 14 Feb 2016 13:13:41 +0000 Received: from maildlpprd54.lss.emc.com (maildlpprd54.lss.emc.com [10.106.48.158]) by mailuogwprd53.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id u1EDDWF0011760 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 14 Feb 2016 08:13:32 -0500 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd53.lss.emc.com u1EDDWF0011760 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1455455612; bh=mYgLwnB0v41MmIWpZhVAGvIM5T4=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=sJKLtfr+wRSX6dzFJk9zDHNKTWJ1nEuaHEgkbOAcn9xV4bmtU/fPuEOSt2+oaYdTU PNtlLaHi6xoyx3Fa/ps3/xpyKW7XEIy6QNl2SNwyNqEUp7HD1cUUDPhTIX0ZDeMO5J DsDcepNXRxk/ciJjn6WmUQzuUYFkgbmyqovXhm4A= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd53.lss.emc.com u1EDDWF0011760 Received: from mailusrhubprd52.lss.emc.com (mailusrhubprd52.lss.emc.com [10.106.48.25]) by maildlpprd54.lss.emc.com (RSA Interceptor); Sun, 14 Feb 2016 08:12:41 -0500 Received: from MXHUB220.corp.emc.com (MXHUB220.corp.emc.com [10.253.68.90]) by mailusrhubprd52.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id u1EDDDvT017790 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Sun, 14 Feb 2016 08:13:14 -0500 Received: from MX105CL01.corp.emc.com ([fe80::e020:347b:74e3:4176]) by MXHUB220.corp.emc.com ([10.253.68.90]) with mapi id 14.03.0266.001; Sun, 14 Feb 2016 08:13:13 -0500 From: "Venkatesan, Sekhar" To: "pgsql-odbc@postgresql.org" , "pgsql-sql@postgresql.org" Subject: PostgreSQL: Inserting NULL values adds empty string. Thread-Topic: PostgreSQL: Inserting NULL values adds empty string. Thread-Index: AdFnKHSBhR/6qCaDR/mlfXFjFt8rAw== Date: Sun, 14 Feb 2016 13:13:13 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.42.34.68] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd52.lss.emc.com X-RSA-Classifications: public X-Pg-Spam-Score: -4.3 (----) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-odbc Precedence: bulk Sender: pgsql-odbc-owner@postgresql.org Hi Folks, I am using PostgreSQL 9.4 odbc driver to talk to 9.4 postgreSQL server. I see that when inserting NULL values into DB is adding empty string in th= e database only in windows. The same insert is adding NULL values into database when linux odbc driver = is used to connect to linux database. Is there any configuration in odbc driver end or in server to retain the n= ull values or is it a bug? If it is not and is an expected behavior, how to fix it in the application? Thanks, Sekhar -----Original Message----- From: Venkatesan, Sekhar=20 Sent: Friday, January 29, 2016 10:04 AM To: 'Joshua D. Drake'; 'pgsql-odbc@postgresql.org' Subject: RE: [ODBC] PostgreSQL: Autocommit through windows odbc driver does= nt work!!! HI Joshua, I perform the following set of operations to set autocommit in postgreSQL t= hrough ODBC in windows. SQLSetConnectAttr(hDbc, SQL_ATTR_AUTOCOMMIT, (SQLPOINTER) SQL_AUTOCOMMIT_ON= , 0) ret =3D SQLDriverConnect(_hdbc, NULL, (SQLCHAR*) dsn.GetChars(), SQL_NTS, N= ULL, 0, NULL, SQL_DRIVER_NOPROMPT); This doesn't enable autocommit. If I call SQLSetConnectAttr after SQLDriver= Connect, autocommit is set. Any issue with this sequence? I assume It should be possible to set SQL_ATT= R_AUTOCOMMIT before establishing connection. Can you please confirm on this behavior? Thanks, Sekhar -----Original Message----- From: Joshua D. Drake [mailto:jd@commandprompt.com] Sent: Thursday, January 28, 2016 11:14 PM To: Venkatesan, Sekhar; pgsql-odbc@postgresql.org Subject: Re: [ODBC] PostgreSQL: Autocommit through windows odbc driver does= nt work!!! On 01/28/2016 08:53 AM, Venkatesan, Sekhar wrote: > Is the above issue fixed? Also in my use-case, I want to enable=20 > autocommit at odbc driver level but even that doesn't work. > > The same application works in Linux OS when unix odbc driver is used. > This seems to be specific to windows driver. > > Please shed some light on this. Do ask me further question if you have an= y. > By default PostgreSQL "autocommits". If it isn't in your case, your driver = is starting a transaction and not committing it. Sincerely, JD --=20 Command Prompt, Inc. http://the.postgres.company/ +1-503-667-4564 PostgreSQL Centered full stack support, consulting and development. --=20 Sent via pgsql-odbc mailing list (pgsql-odbc@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-odbc