transacciones into ejemplos comandos columns sql-server tsql centos connection-pooling

sql server - into - la conexión a tdsool se agota con tsql



sql server split string into columns (2)

Tuve un problema similar. Trataremos de ayudarte a resolver tu. Primero, asegúrese de que su /etc/freetds.conf contenga una configuración válida:

[global] tds version = 4.2 ... [myserver] host = <ip> port = 1433 tds version = 4.2 < this is important

Ahora, /etc/tdspool.conf

[sampool] user = [REDACTED] password = [REDACTED] database = [REDACTED] server = myserver < important port = 1313

Entonces tdspool sampool debería comenzar bien. Mis errores fueron los siguientes: 1. Pensé que el servidor en pool.conf es ip o dominio del servidor, mientras que realmente eso es referencia al servidor en freetds.conf 2. En freetds.conf utilicé la versión incorrecta (demasiado alta) de tds. Tdspool admite versiones de tds hasta 4.2, como se indica en sus documentos.

Ahora, si intentas conectarte mediante tsql -S 172.0.0.1:1313, aún obtendrás "aceptación de conexión ..." para siempre. PERO, si lo haces

tsql -S 127.0.0.1:1313 -U <username> -P <password> -D <database>

te conectarás y podrás ejecutar consultas en tu servidor sql a través de tdspool.

Estamos usando tdspool y tratando de conectarnos usando tsql localmente en la misma máquina. tdspool parece abrir sus conexiones perfectamente y comienza a escuchar, sin embargo, cualquier cliente que se conecte a la agrupación agota el tiempo de espera.

pool.conf

[global] min pool conn = 5 max pool conn = 10 max member age = 120 [sampool] user = [REDACTED] password = [REDACTED] database = [REDACTED] server = [REDACTED] port = 1313 ;change to a non standard port so we can see the connection details in the debug log

Al conectarse a 127.0.0.1:1313 utilizando tsql, la salida de tdspool simplemente dice "aceptar conexión" y nada más. El archivo freetds.log genera lo siguiente:

dblib.c:1237:tdsdbopen: Calling tds_connect_and_login(0x2b3fec0, 0x2b40580) iconv.c:328:tds_iconv_open(0x2b3fec0, UTF-8) iconv.c:187:local name for ISO-8859-1 is ISO-8859-1 iconv.c:187:local name for UTF-8 is UTF-8 iconv.c:187:local name for UCS-2LE is UCS-2LE iconv.c:187:local name for UCS-2BE is UCS-2BE iconv.c:346:setting up conversions for client charset "UTF-8" iconv.c:348:preparing iconv for "UTF-8" <-> "UCS-2LE" conversion iconv.c:395:preparing iconv for "ISO-8859-1" <-> "UCS-2LE" conversion iconv.c:400:tds_iconv_open: done net.c:202:Connecting to 127.0.0.1 port 1313 (TDS version 7.3) net.c:274:tds_open_socket: connect(2) returned "Operation now in progress" net.c:313:tds_open_socket() succeeded util.c:165:Changed query state from DEAD to IDLE packet.c:740:Sending packet 0000 12 01 00 3a 00 00 00 00-00 00 1a 00 06 01 00 20 |...:.... ....... | 0010 00 01 02 00 21 00 0c 03-00 2d 00 04 04 00 31 00 |....!... .-....1.| 0020 01 ff 09 00 00 00 00 00-02 4d 53 53 51 4c 53 65 |........ .MSSQLSe| 0030 72 76 65 72 00 96 24 00-00 00 |rver..$. ..| util.c:322:tdserror(0x2a6b8c0, 0x2b3fec0, 20003, 115) dblib.c:7897:dbperror(0x2b3f3b0, 20003, 115) dblib.c:7965:dbperror: Calling dblib_err_handler with msgno = 20003; msg->msgtext = "Adaptive Server connection timed out (127.0.0.1:1313)" dblib.c:5743:dbgetuserdata(0x2b3f3b0) dblib.c:7987:dbperror: dblib_err_handler for msgno = 20003; msg->msgtext = "Adaptive Server connection timed out (127.0.0.1:1313)" -- returns 2 (INT_CANCEL) util.c:352:tdserror: client library returned TDS_INT_CANCEL(2) util.c:375:tdserror: returning TDS_INT_CANCEL(2) query.c:3769:tds_disconnect() util.c:165:Changed query state from IDLE to DEAD login.c:472:login packet rejected util.c:322:tdserror(0x2a6b8c0, 0x2b3fec0, 20002, 0) dblib.c:7897:dbperror(0x2b3f3b0, 20002, 0) dblib.c:7965:dbperror: Calling dblib_err_handler with msgno = 20002; msg->msgtext = "Adaptive Server connection failed (127.0.0.1:1313)" dblib.c:5743:dbgetuserdata(0x2b3f3b0) dblib.c:7987:dbperror: dblib_err_handler for msgno = 20002; msg->msgtext = "Adaptive Server connection failed (127.0.0.1:1313)" -- returns 2 (INT_CANCEL) util.c:352:tdserror: client library returned TDS_INT_CANCEL(2) util.c:375:tdserror: returning TDS_INT_CANCEL(2) dblib.c:1241:tdsdbopen: tds_connect_and_login failed for "127.0.0.1:1313"! dblib.c:1463:dbclose(0x2b3f3b0) dblib.c:243:dblib_del_connection(0x7fa27f9644a0, 0x2b3fec0) mem.c:648:tds_free_all_results() dblib.c:290:dblib_release_tds_ctx(1) dblib.c:5845:dbfreebuf(0x2b3f3b0) dblib.c:743:dbloginfree(0x2b3ef10) dblib.c:1533:dbexit(void) dblib.c:1533:dbexit(void) dblib.c:290:dblib_release_tds_ctx(1)

tsql -C:

Version: freetds v0.95.19 freetds.conf directory: /etc MS db-lib source compatibility: yes Sybase binary compatibility: no Thread safety: yes iconv library: yes TDS version: 5.0 iODBC: no unixodbc: yes SSPI "trusted" logins: no Kerberos: no OpenSSL: no GnuTLS: no

Sistema operativo: CentOS 6.5


El software está dañado

Fuimos a la lista de correo oficial y le hicimos esta pregunta textualmente. La respuesta parece ser que no hay uno sin reescribir el proyecto actual.

Las bibliotecas de cliente se utilizan y se prueban bien, pero el conjunto y el servidor no están realmente en buena forma.

El estado actual de tdspool es ... ¡compila! No estoy sorprendido de que no se ejecute correctamente.

Eso dijo que es de código abierto. Cualquier ayuda / sugerencia / parche es bienvenido.

Pasamos una cantidad de tiempo considerable tratando de descubrir qué estábamos haciendo mal, así que esto es un poco doloroso. Mientras busco crear / modificar pools de SQL Server existentes, me decepciona que FreeTDS (un maravilloso proyecto) se envíe con un grupo tan inestable