Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nYDH5-0008Tj-8m for pgsql-odbc@arkaria.postgresql.org; Sat, 26 Mar 2022 20:44:39 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1nYDH3-0004UG-SK for pgsql-odbc@arkaria.postgresql.org; Sat, 26 Mar 2022 20:44:37 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nYDH3-0004U7-Bg for pgsql-odbc@lists.postgresql.org; Sat, 26 Mar 2022 20:44:37 +0000 Received: from sonic309-21.consmr.mail.ne1.yahoo.com ([66.163.184.147]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1nYDH0-00085H-6y for pgsql-odbc@lists.postgresql.org; Sat, 26 Mar 2022 20:44:36 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1648327472; bh=5UxEdGX/uqOljxZV/29dPR9UJRmHud6+jRp041U3MoY=; h=Date:From:To:In-Reply-To:References:Subject:From:Subject:Reply-To; b=PPu0s7M+4rusmngJFR7tB62XyyM6vwqrTDL13nsYOw37Sha3uzuj4HlcIH3wwkXChh3Dy0fZ09cUELPUHEv3kA8Ywhfp6DhE80rCZqnsC/OOe1vyEcv2sgBlNTKxqzm+gYe5w/REHwNG2XEUGoRzmSHMNz1XVKBMxwKC1vZmSP377XpT16sC7kdwqmCnzk9o5jsRMTsUG9GTBY0dbplPt3t0upnY91bMTiSLLa7JIJDbh8EGaBxJaWiiVRbqHLtxu+4XBZUxeRGyRFflBMbZXy0YEKrYpJWpnkP3aK0MdVwyamXlnABn3abpRkQ+UxBwVzSmiq1KP2dJonxuoIp+PA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1648327472; bh=DLBBmKlGrFXCmqqV8ODPy5AYvzlPS7YC9+9cVhxuWFe=; h=X-Sonic-MF:Date:From:To:Subject:From:Subject; b=fta8xrfGYuFocvCg1juKUq41B1mD8ccE/ea7se32uPaXjzTHhfd9ppw4vDs2zW5DYENBCxKw+FvugErYoCpRqslMgkBXQTJbMQpTGROfXrqj9mnDQ1Gm+gj3LQ9HUMWyXrS3pVVq5SdDKUx64GYB7MxzVzpoN+XTlgeKKyVyzAsV24yHS28asiqdA0bg/AhYc031I9N32zTXlrs73+z6QfzrG1LlHasQiCw+cH4zZzlOjaFFVUuErrgx/SQEXTYad6LITLjzi+UTJnR/qhmYXdwbUvILxjgVYF0sWz986lcDASD9yTua1QTcZco8N8v5E5Nf9ems5gCIcZ6KNDi2PQ== X-YMail-OSG: _K80hAcVM1nj_oK1Bj8nuN46yBOJ0kGDvyqEzxwz89Gu.BpA7X.vYUz4naGKTdi QhWDVrUg8FGLOfPzW5MqUw2gllLYcF1TmP5c3qyDRmZP00Mk8LOPTOWd4LK1kcde3aSzUkYFgLBF 4HvoX4J_FdwxJv2msM8cXRmYBHOe09gfv7X3lWHI0dpiXXCcqz.Og4oLsSutuUAJyVfFvXyI91Nu ubj0sthgMaZJbVy5PdyZQoxdGy2YUwbHZDA8hfgyg.gzKQLYD.g8M5ralfzuEOiYrpASQVPL8h7y ZWubskNEV1uh3TUnauUDOt7mnr.6Vk7DxVKZwlPTbhZ.kjXLSF2APg1b3a_5YdQOxiqdziaItbdv L0ajWOISxHr6HwPZLB0pqb0XPZjYM4tm9LDu8m3v_wvzT.Rdzhx9ABG08ckaGqHBnCtIIbQZEYrn soABYJ.xlhC8jH3lTHZb7A6F8Yoki0j2gJyFCbnt8Kt7vQArS3ZR9ZayqhAmp_ri.yjrqyunJ8_G 6EspLYAPZ7mDhrItgiZykv7CATCHiYHed8NBRFPu8QvnTCfof5QnPa.kJkwfOl2qPbBJjqBhhuFN EYQ9obpJHe5iq33O.GAcQSM.zqLkAosilwoFHh5pICWEgLej64AOOjGQddRgCNNNGPr7tpXxLDX6 7WxyyWmLbwcDb2_0rb0oII39gxOaf0DSePHFY_JKjweNnL7yM3uvKiAo_7sBeiC3TKsH8V866aAa ka6e_UMuiXNzOWT9R04zHM5iPx62qdzWFX7iNPXkIPnAys9B4n_qTB9oNFuwvPEWmUXcMfl7.Fl0 c0sYxcCVkhjnJZtpn6yhRNP8bFrhV98z1xe9q9u3geOH3ruRm5NFr3YgTotmdlN2L1J.B3Efum.z nGB8Rj2Jb5ofVALMSA9qc_C2vAVwJnu2sE6_kA6Q553EKDcs4GZAXeFDIl9_XmkMDnS8hGbe9CLX aTUzt2GZ9.JU.SM744RmjqKb_VDHi_TI8zOzWYyLWN3.SCoiyrYe21PpaJ9HJZ09ClcHdq2cM3h4 QYFgLX_PeAB9m.aEV7arrDKBQelmPmrAlhcseZO6wKJfaCX.RI2nr9bisV3ruoCc8Pj2pGX6ysOb eU9avt8tN4klX1ed7mdx8LKrWAjQy4tRfO36AjjVlDxkhcinv8ZKQvXQfY6iu388KreakLR.6f85 WnkorW5EUYOLm3imPJ4UIQgO_OcHOrh2bB8FkyDhQScRo8UAYbxbu9XDlK.jdzRt8EddEivnLOrX udfs90p1YaLvySWVBLwVALQ5gh6lFX1jfpgt0TxtKMDrLtwYe1iwgjWK._1_mfSUJfnVIWL14YLk emkVEsvtBuVIpzSEgRcKMMhLJ.i.1ohl0FxjxIy.MA1pL1dTOpRii24FaXvFhMLtQS0dsboXcYua Popx6j_aUHbBKPMKR2L0j4c1GIzusH9FjeuU0HXMapdo.T5ylDAN84UMSc9gAg8Xs5mLp4NMaJrW LON8zHyyzxG1vrmwi8jK_Amntuq8iq5m2UzDVKqSdkhmJ_kX5b8B4fEmyByCbRQIy8q4_Ow8D90P MDA_upcEW8Nf11m.kXx_ddW8_sKHm4vAu_J0X75v_JTj5u0JcLwWTwNcYnkdVxdXwSaFpLnJATN9 5q0wJoPCM3gsVoBZ2WVLmOUGOn0YHv.Lg2.GvRZjw2XIOxOQY09JA66yCWiwK0LUlF8On42dUgUO jOQHg5epzB6.JlOvTJpXVIq3X0.AnsDH2UXJhFHJ6P3d4XRV4ZpZCPToId76F8je8tG7mB3IMJBO BMbVhMRmnrKdV.S5gw1BHpzTwFab.zLHCIHm3Asd93gjvPAl83LaXQZNHpTXsdxCvRQRJIBNry8I yeCNXUYBUMyn7g4RJuY4VCjxwvu9p8zpNTn7zT_YUUyNmD1BotFatqD16ffKqwwZSWUsOJCrP7yp qzCT2GbtovUm0zsoNoz35S7t2I3TYivNJrTwxOiw0bUY2BZm_NrDuof.gDJ6bdAi3LfQb8pEjmyl gwrVx99LFbxhs4i0pM_BJgemRtNjaNthcNKEuQ2uywRuUeOoJV_E1IYjnR2B5eIMEfcWY4to_yn0 jUpglbw64aEOmFV0XlKR9l9L8jVSdx5Dy1Gz284EDZOAzLLGiUN_HotXaL.kwegaW7U0HWgqd_B6 nxdeVa.3dwWlbVg4hYkFL.ify6JVjqawnQbYHycyip7pP1iuX.f62pC8lOi00kPpGwgqoosRvwWi VVu6WxMs7fy9YU0zxB0efE7qFBCpFLg-- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic309.consmr.mail.ne1.yahoo.com with HTTP; Sat, 26 Mar 2022 20:44:32 +0000 Date: Sat, 26 Mar 2022 20:44:30 +0000 (UTC) From: Matthew Reeves To: pgsql-odbc@lists.postgresql.org Message-ID: <1796959239.619342.1648327470705@mail.yahoo.com> In-Reply-To: <1154651790.1143593.1647808005653@mail.yahoo.com> References: <1154651790.1143593.1647808005653.ref@mail.yahoo.com> <1154651790.1143593.1647808005653@mail.yahoo.com> Subject: Re: PostgreSQL via PolyBase (MS-SQL) - Numeric Data Type Issue MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_619341_1752988392.1648327470704" X-Mailer: WebService/1.1.19987 YMailNodin Content-Length: 6892 List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk ------=_Part_619341_1752988392.1648327470704 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hello, everyone, As a follow-up, I downloaded the source code for the psqlODBC driver. The i= ssue I described is cause by the call to function SQLSetDescRec, which, as = of version 13.02.0000, has not yet been implemented. When the MS-SQL PolyBa= se component calls the function, the psqlODBC driver returns a SQL_ERROR wi= th the message "Error not implemented", so MS-SQL responds to the client wi= th error IM001: Driver does not support this function. Does anyone know if/when this function is expected to be implemented in the= psqlODBC driver? Matthew On Sunday, March 20, 2022, 01:27:01 PM PDT, Matthew Reeves wrote: =20 =20 Hello, everyone, I am hopeful that there is someone in the PG community who can help with th= is one. Our company has a MS-SQL data-warehouse, and we have a requirement to incor= porate data from a PostgreSQL ERP database into this environment.=C2=A0 We = have elected to do so via the MS-SQL PolyBase component. We have installed the psqlODBC drivers (psqlodbc_13_02_0000) on the MS-SQL-= Server.=C2=A0 The master key, database scoped credential and external data = source have all been created, and external table links work as expected, wi= th the exception of any tables containing numeric or decimal fields (ex. nu= meric(18,2), decimal(18,2)).=C2=A0 When the MS-SQL-Server instance attempts= to execute a query on such a table, the following error is returned: Cannot execute the query "Remote Query" against OLE DB provider "MSOLEDBSQL= " for linked server "(null)". 105082;Generic ODBC error: OdbcBufferReader.R= eadBuffer, error in OdbcReadBuffer: SqlState: IM001, NativeError: 0, 'Error= calling: SQLSetDescRec(this->GetHdesc(), (SQLSMALLINT)column->idxServerCol= , (SQLSMALLINT)column->odbcReadType, 0, column->valueLength, (SQLSMALLINT)c= olumn->precision, (SQLSMALLINT)column->scale, (SQLPOINTER)(pBuffer + column= ->valueOffset), (SQLLEN *)indPtr, (SQLLEN *)indPtr), SQL return code: -1 | = SQL Error Info:=C2=A0 Error <1>: ErrorMsg: [Microsoft][ODBC Driver Manager]= Driver does not support this function | Error calling: pReadConn->ReadBuff= er(pBuffer, bufferOffset, bufferLength, pBytesRead, pRowsRead) | state: FFF= F, number: 566, active connections: 7', Connection String: DSN=3DPOSTGRESQL= ERP. The only workaround that I have seen posted on the web thus far is to map t= he PostgreSQL numeric data type, on the MS-SQL side, as an INT type.=C2=A0 = This works for any numeric fields where the scale is 0 (ex. numeric(10,0)).= =C2=A0 However, for any of the tables from the ERP financial module, where = fields are defined as numeric(18,2), for example, this is not a viable solu= tion. I look forward to hearing from you, Matthew =20 ------=_Part_619341_1752988392.1648327470704 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello, everyone,

As a follow-up, I downloaded t= he source code for the psqlODBC driver. The issue I described is cause by = the call to function SQLSetDescRec, which, as of version 13.02.0000, has no= t yet been implemented. When the MS-SQL PolyBase component calls the funct= ion, the psqlODBC driver returns a SQL_ERROR with the message "Error n= ot implemented", so MS-SQL responds to the client with error IM001: Dr= iver does not support this function.

Does anyone know if/when this f= unction is expected to be implemented in the psqlODBC driver?


Ma= tthew
=
=
On Sunday, March 20, 2022, 01:27:01 PM PDT= , Matthew Reeves <bytemyzer@yahoo.com> wrote:
=


=
Hello, everyone,

I am hopeful that there is someone in the PG community wh= o can help with this one.

Our company has a MS-SQL data-warehouse, and we have a requirement to i= ncorporate data from a PostgreSQL ERP database into this environment. = We have elected to do so via the MS-SQL PolyBase component.

We have installed the psqlODBC drive= rs (psqlodbc_13_02_0000) on the MS-SQL-Server.  The master key, databa= se scoped credential and external data source have all been created, and ex= ternal table links work as expected, with the exception of any tables conta= ining numeric or decimal fields (ex. numeric(18,2), decimal(18,2)).  W= hen the MS-SQL-Server instance attempts to execute a query on such a table,= the following error is returned:


Cannot execute the query "Remote Que= ry" against OLE DB provider "MSOLEDBSQL" for linked server "(null)". 105082= ;Generic ODBC error: OdbcBufferReader.ReadBuffer, error in OdbcReadBuffer: = SqlState: IM001, NativeError: 0, 'Error calling: SQLSetDescRec(this->Get= Hdesc(), (SQLSMALLINT)column->idxServerCol, (SQLSMALLINT)column->odbc= ReadType, 0, column->valueLength, (SQLSMALLINT)column->precision, (SQ= LSMALLINT)column->scale, (SQLPOINTER)(pBuffer + column->valueOffset),= (SQLLEN *)indPtr, (SQLLEN *)indPtr), SQL return code: -1 | SQL Error Info:=   Error <1>: ErrorMsg: [Microsoft][ODBC Driver Manager] Driver d= oes not support this function | Error calling: pReadConn->ReadBuffer(pBu= ffer, bufferOffset, bufferLength, pBytesRead, pRowsRead) | state: FFFF, num= ber: 566, active connections: 7', Connection String: DSN=3DPOSTGRESQLERP.


The only workaround that I have seen posted on the web thus far is to m= ap the PostgreSQL numeric data type, on the MS-SQL side, as an INT type.&nb= sp; This works for any numeric fields where the scale is 0 (ex. numeric(10,= 0)).  However, for any of the tables from the ERP financial module, wh= ere fields are defined as numeric(18,2), for example, this is not a viable = solution.


I look forward to hearing from you,

Matthew


------=_Part_619341_1752988392.1648327470704--