#odbc

https://www.infometry.net/product/netsuite-to-snowflake-connector/

Avete mai avuto la necessità di accedere ai dati di un server MySQL da una istanza SQL Server? Ovviamente è possibile farlo utilizzando le tante funzionalità di export e import previste dai due sistemi, ma in questo caso intendiamo proprio la possibilità di effettuare delle vere e proprie query in tempo reale, così da poter utilizzare i dati presenti sul server MySQL all'interno di JOIN, MERGE e altri comandi similari. In questo articolo cercheremo di spiegare come è possibile farlo creando un apposito Linked Server (Server Collegato, nella traduzione italiana), una funzionalità di SQL Server che può essere utilizzata per accedere ad altre sorgenti di dati attraverso una serie di provider disponibili: nello specifico, vedremo come è possibile creare un Linked Server che punti a una istanza MySQL ubicata su una macchina accessibile tramite LAN.

Installare il MySQL Connector

La prima cosa da fare è scaricare il MySQL Connector per ODBC e installarlo sulla macchina che ospita l'istanza SQL Server sulla quale vogliamo creare il Linked Server. Questa operazione è fondamentale per rendere il server in grado di potersi connettere a MySQL. L'ultima versione del MySQL Connector per ODBC può essere scaricata al seguente indirizzo: https://dev.mysql.com/downloads/connector/odbc/ Assicuratevi di scaricare la versione adatta all'architettura della macchina (x86 o x64). Inoltre, potrebbe essere necessario installare l'ultima versione dei seguenti bundle: Microsoft Data Access Components (MDAC) (ad oggi 2.8 SP1), scaricabile a questo indirizzo. Microsoft Visual C++ Redistributable Package (ad oggi 2015-2019), scaricabile a questo indirizzo. Una volta installato il connector, sarà possibile creare il Linked Server.

Creare il Linked Server

Il Linked Server può essere creato in due modi: Aggiungendo un Data Source dedicato tramite lo strumento ODBC Data Source presente nel Pannello di Controllo di Windows. Senza aggiungere un Data Source dedicato, ovvero configurando le impostazioni di connessione direttamente all'interno del Linked Server. La prima modalità è indubbiamente più laboriosa, ma da un punto di vista di sicurezza è preferibile in quanto, come avremo modo di vedere tra poco, consente di evitare la presenza della connection string in chiaro, evitando quindi di dover esporre le credenziali di accesso a MySQL. Con Data Source dedicato Per creare il Linked Server mediante l'aggiunta di un Data Source dedicato, eseguire le seguenti operazioni: Navigare all'interno del Pannello di Controllo > Strumenti di amministrazione, quindi lanciate lo strumento Origini Dati ODBC (32 bit o 64 bit a seconda dell'architettura della macchina). Selezionare la tab DNS di sistema, quindi fare click su Aggiungi per aggiungere un nuovo Data Source. Nella finestra Crea nuova origine dati che si aprirà, selezionare il Driver MySQL Unicode, come illustrato nella screenshot seguente, quindi fare click su Fine.

Nella finestra successiva sarà possibile configurare il Data Source inserendo il nome, una breve descrizione, e ovviamente i dati di connessione, comprensivi di username, password e database predefinito. La screenshot seguente mostra un esempio di compilazione per la connessione a un database installato sulla porta MySQL di default raggiungibile tramite un dato indirizzo di rete locale.

IMPORTANTE: Prendete nota del Data Source Name che sceglierete, in quanto dovrete utilizzarlo più avanti. Subito dopo aver compilato i parametri del caso, sarà possibile verificare la connessione al server MySQL facendo click sul pulsante Test: inutile dire che, affinché il test funzioni, è necessario che il server risulti accessibile, quindi occorrerà configurare l'eventuale firewall nel modo opportuno. Una volta creato il Data Source, occorrerà creare il Linked Server vero e proprio. Il modo migliore per farlo è utilizzando SQL Server Management Studio (SSMS), lo strumento gratuito fornito da Microsoft per gestire istanze SQL Server locali e/o remote: l'ultima versione (ad oggi la 18.5) è disponibile a questo indirizzo. Una volta scaricato e installato SSMS, utilizzatelo per connettetevi all'istanza SQL Server sulla quale desiderate creare il Linked Server. Dalla finestra denominata Object Explorer espandete il nodo Server Objects, quindi fate click con il tasto destro su Linked Servers e selezionate New Linked Server, come nella screenshot seguente:

Nella schermata che si aprirà sarà possibile impostare i parametri del linked server nel seguente modo: Linked Server: il nome da assegnare al Linked Server, ovvero quello che dovrete utilizzare all'interno delle varie query. Server Type: il tipo di server a cui ci si connette: poiché intendiamo connetterci a un Server MySQL, selezionate Other data source. Provider: Il provider da utilizzare per la connessione: poiché il connector per MySQL funziona tramite ODBC, selezionare Microsoft OLE DB Provider for ODBC Drivers. Product name: Inserite MySQL. Data Source: inserite il Data Source Name relativo al Data Source creato in precedenza (nell'esempio illustrato nella screenshot di poco fa il nome è "Mantis Bug Tracker").

Una volta configurati i parametri generali, spostatevi nella tab Security, dove sarà necessario: Selezionare l'opzione Be made using this security context. Inserire nuovamente le credenziali di autenticazione per connettersi al Database MySQL.

Fatto questo, sarà possibile fare click sul pulsante OK e completare la creazione del Linked Server. Senza Data Source dedicato Nel caso in cui si preferisse creare il Linked Server senza un Data Source dedicato, sarà possibile farlo direttamente dello strumento SSMS, evitando quindi tutta la parte legata al Pannello di Controllo e allo strumento ODBC Data Source, svolgendo le seguenti operazioni: Lanciare SQL Server Management Studio (SSMS). Collegarsi al Server SQL su cui si desidera creare il Linked Server. Dalla finestra Object Explorer espandere il nodo Server Objects, quindi click con il tasto destro su Linked Servers e selezionare New Linked Server. Creare il Linked Server come illustrato nella screenshot seguente:

Come si può vedere, stavolta anziché specificare il nome del Data Source (che non abbiamo creato) è necessario indicare la Connection String da utilizzare per connettersi al Database, che dovrà avere questo formato: Driver={MySQL ODBC 8.0 Unicode Driver};DATABASE=database_name;OPTION=134217728;PWD=user_password;UID=user_identification;SERVER=server_name Una volta inserita la Connection String, passare alla tab Security e compilarla nello stesso modo indicato in precedenza, ovvero: selezionando l'opzione Be made using this security context. Inserendo le credenziali di autenticazione per connettersi al Database MySQL.

Utilizzare il Linked Server

Una volta creato il Linked Server è possibile interrogarlo nei seguenti modi: Tramite la cosiddetta "three dot notation", ovvero la sintassi utilizzata da SQL Server per effettuare query sui server collegati: SELECT * FROM ...; Tramite la funzione OPENQUERY, utilizzabile nel seguente modo: SELECT * FROM OPENQUERY(, 'SELECT * FROM mantis.mantis_bug_table'); In entrambi i casi, se i passaggi illustrati saranno stati svolti correttamente, riusciremo a visualizzare i dati presenti nella tabella MySQL direttamente da SQL Server. La differenza principale tra le due modalità illustrate è che la three dot notation prevede l'utilizzo della sintassi T-SQL, mentre la funzione OPENQUERY consente l'utilizzo della sintassi tipica di MySQL, con tutte le funzioni supportate dal server MySQL collegato: sarà quindi possibile utilizzare funzionalità specifiche di quel database, come ad esempio l'utilissimo comando LIMIT.

Conclusione

Microsoft 自 SQL Native Client 11後便不再支援SQL Server 2000的連線了，也因此導致使用SQL Native Client 11的SQL Server 2012、2014無法直接用DB Link連結SQL Server 2000。

解套的方式就是安裝SQL Native Client 10（可從SQL Server 2008、2008 R2的安裝檔中提取），在使用ODBC的方式連結。

Well well.. Took me a while (http://damjan.cvetko.org/post/95985934678/tracing-php-errors) to get around to this.

I was forced to look again at the issue where we use PHP, unixODBC and FreeTDS to connect to a MSSQL server. At first, PHP would just seem to randomly crash, when turning it around a bit it would try to allocate obscene amounts of memory:

PHP Fatal error:  Allowed memory size of 536870912 bytes exhausted (tried to allocate 4294967293 bytes) in /home/test/crash.php on line 11

With some poking around, I was able to reliable reproduce the issue specific rows and columns so that the issue would happen right away with one one-row query. The column in question was a varchar and it had unicode characters (ČŠŽ...).

Since I was riding a new and current SLES and had all packages from either official or Leap repos, I could get my hands on some debuginfo and sources.

Some very nice SLES commands.

zypper ca

zypper mr -e SLE-Module-Web-Scripting12-Debuginfo-Updates

zypper install php5-debuginfo-5.5.14-109.8.2.x86_64

zypper install --oldpackage php5-odbc-debuginfo-5.5.14-109.8.2.x86_64

zypper lr -u  (To get Repo links and Tokens for manual SRC downloads)

Armed with some source and debug symbols, I could figure out that on fetch of such particular columns the vallen was -4, even though the value content seemd ok. Naturaly, the poor php5-odbc would crash and burn (function odbc_result):

if ((int)result->values[field_ind].vallen == (int)SQL_NULL_DATA) {   RETURN_NULL(); } else {   RETURN_STRINGL(result->values[field_ind].value, result->values[field_ind].vallen, 1); }

Hint: RETURN_STRINGL does a estrndup with a -4 that is unsigned (you guessed it) 4294967292 (+1 for and extra \0, but that’s not the point).

Ok, where does -4 come from?

/etc/freetds.conf dump file = /tmp/freetds.log dhowd had some raw network dumps, which all looked OK, but it did however give an important clue. 

01:56:22.124959 6458 (iconv.c:330):tds_iconv_open(0x55c2a9511180, CP1250) 01:56:22.125024 6458 (iconv.c:187):local name for ISO-8859-1 is ISO-8859-1 01:56:22.125031 6458 (iconv.c:187):local name for UTF-8 is UTF-8 01:56:22.125033 6458 (iconv.c:187):local name for UCS-2LE is UCS-2LE 01:56:22.125035 6458 (iconv.c:187):local name for UCS-2BE is UCS-2BE 01:56:22.125037 6458 (iconv.c:349):setting up conversions for client charset "CP1250" 01:56:22.125039 6458 (iconv.c:351):preparing iconv for "CP1250" <-> "UCS-2LE" conversion 01:56:22.125089 6458 (iconv.c:391):preparing iconv for "ISO-8859-1" <-> "UCS-2LE" conversion

FreeTDS performs iconv conversions and since I suspected our lovely Slavic script to be at the heart of  the issue, I went digging into FreeTDS next. Behold, freetds/convert.h:

#define TDS_CONVERT_NOMEM -4 /* insufficient memory */

The darn thing returns its internal errors in the length of the field when calling SQLFetch (length is bound with SQLBindCol).

I did some poking around with gdb, but in the end couldn’t pinpoint exactly why the allocation failed. Not enough memory, surely not.

I did try a different approach. Can I skip iconv translation completely? I went back to freetds.conf and set the charset to the native one, in my case CP1250.

Crashes were no more. I could now do my own iconv call to translate the encoded data to UTF-8 in PHP. Worked like a charm.