He buscado documentacion de los SELECT pero es muy pobre para ver que tanto se puede hhacer con las sentecias SQL
Gracias con tu ayuda ya solucione donde estaba envolatado nunca he usado OPENADS, toca leer mas.
Con el navegador si puedo hacer el browser perfecto , pero SQL no lo genera, AL Darle Run el mensage es 500 internal server error
Me alegra que ya hayas resuelto el punto donde estabas atascado, Rubén.
Para ver qué consultar, separaría dos lecturas:
Son fuentes actuales de la rama main, no una comprobación de que cada construcción esté disponible y funcione igual en tu versión 1.09.74. El ejemplo además crea y borra tablas de prueba: no lo adaptes apuntando a tus datos reales.
Si tienes una consulta concreta que quieras expresar, pega el SELECT deseado y una estructura mínima inventada de las tablas. Así podemos revisar ese caso, en vez de asumir compatibilidad con cualquier sentencia de otro motor SQL.
Perfecto voy a revisarlo para ver la JOIN Con el navegador si puedo hacer el browser perfecto , pero SQL no lo genera, AL Darle Run el mensage es 500 internal server error
Rubén, esto es distinto de la consulta que ya conseguiste ejecutar desde Harbour: ahora falla Run en la consola web, aunque la vista de tablas funciona. El mensaje HTTP 500 por sí solo no permite saber qué ocurrió ni demuestra que el JOIN no esté admitido.
He revisado la ruta SQL del servidor en el código público de v1.09.74: el endpoint POST /api/sql ejecuta la consulta y devuelve un cuerpo JSON. Hay una ruta que devuelve 500 si no puede abrir el directorio de datos; en cambio, el error recogido de AdsExecuteSQLDirect se devuelve allí con estado 400 y una descripción. Son rutas distintas, no un diagnóstico de tu caso, y aún no hemos confirmado que el ejecutable del servicio corresponda exactamente a ese código.
La comprobación útil es recoger el detalle que acompaña a ese 500:
No publiques cookies, cabeceras de autorización, credenciales, datos devueltos por la consulta ni un archivo HAR completo. Tampoco hace falta reinstalar el servicio, cambiar DLL o abrir puertos para obtener estos datos.
Fuente revisada:
https://raw.githubusercontent.com/FiveTechSoft/OpenADS/v1.09.74/tools/serverd/http_server.cpp
dandole una mano a ruben por anydesk, pdimos realizar la conexion remota.
pero tengo un problema:
yo en ads hay ocaciones en que deseo realizar consultas, y que el resultado me lo regrese en un cursor o area, esto me funciona muy bien con ads32
pero con openads falla:
#include "common.ch"
#include "fivewin.ch"
#include "ads.ch"
REQUEST ADS
REQUEST DBFCDX, DBFFPT
REQUEST HB_LANG_ESWIN, HB_CODEPAGE_ESWIN
EXTERNAL OrdKeyNo, OrdKeyCount, OrdKeyGoTo, OrdKeyRelPos
EXTERNAL AdsKeyNo, AdsKeyCount, AdsGetRelKeyPos, AdsSetRelKeyPos
PROCEDURE Main()
LOCAL cConnect := "tcp://127.0.0.1:6262//misapp/openads/datos_prueba/prueba.add"
LOCAL cUser := ""
LOCAL cPass := ""
LOCAL cError := ""
LOCAL hConn := 0
SET DECIMAL TO 4
SET EPOCH TO 1990
SET DATE BRIT
SET SOFTSEEK OFF
SET CENTURY ON
SET OPTIMIZE ON
SET CONFIRM ON
HB_LangSelect( "ESWIN" )
HB_SetCodePage( "ESWIN" )
? "ACE DLL reports:", AdsVersion()
AdsSetServerType( ADS_REMOTE_SERVER )
RddSetDefault( "ADS" )
AdsSetCharType( ADS_ANSI )
AdsRightsCheck( FALSE )
AdsLocking( FALSE )
AdsSetFileType( ADS_ADT )
IF ! AdsConnect60( cConnect, ADS_REMOTE_SERVER, cUser, cPass, 0, @hConn ) .OR. hConn == 0
AdsGetLastError( @cError )
?"Error de conexion o credenciales invalidas: ", cError
RETURN
ENDIF
? "Conexion y autenticacion exitosas con el diccionario!", "CONN:" + hb_ntos( hConn ), "Tipo:" + hb_ntos( AdsGetConnectionType( hConn ) )
USE clientes VIA "ADS" SHARED NEW ALIAS "prueba" //aca funciona bien, con varias tablas, entre ella rutas, que falla en la sql
GO TOP
IF NetErr()
MsgStop( "No se pudo abrir la tabla. Verifica permisos del usuario.", "Error" )
ELSE
XBROWSER( "prueba" )
CLOSE ALL
DBSelectArea(0)
ADSCreateSQLStatement( "MYTMP", 2, hConn )
IF ADSExecuteSQLDirect( "SELECT * FROM rutas;" )
DBSelectArea("MYTMP")
MYTMP->( xbrowse() )
MYTMP->( DBCloseArea() )
ELSE
AdsGetLastError( @cError )
?"Error de SQL: ", cError
ENDIF
ENDIF
AdsDisconnect( hConn )
RETURNerror
---------------------------
Alert
Error de SQL:
Error 7200: AQE Error: State = 42000; NativeError = 2115; [iAnywhere Solutions][Advantage SQL Engine]ExecuteSQL: server-side exec failed
Aceptar
aca es ADSExecuteSQLDirect retorna falso, por que falla
IF ADSExecuteSQLDirect( "SELECT * FROM rutas;" )
DBSelectArea("MYTMP")
MYTMP->( xbrowse() )
MYTMP->( DBCloseArea() )
ELSE
AdsGetLastError( @cError )
?"Error de SQL: ", cError
ENDIFhay algo extraño, la tabla clientes tiene bastantes datos, si el sql es con la tabla clientes
da el error mostrad, pero si el sql es para la tabla rutas, la tabla es creada, pero vacia.
sera problema de buffer o algo asi?
Carlos, sí: el resultado de una consulta SQL puede quedar en un área de trabajo para recorrerlo o mostrarlo con un browse. En el rddads público de Harbour, AdsCreateSQLStatement crea esa área y la deja seleccionada; AdsExecuteSQLDirect ejecuta sobre ella y, si devuelve un cursor, lo abre en esa misma área. El esquema que buscas no necesita convertir el resultado a un array.
El fallo que muestras ocurre antes de llegar al xbrowse. En el código público de OpenADS v1.09.74, el mensaje «ExecuteSQL: server-side exec failed» lo devuelve el servidor cuando falla su ejecución SQL interna. Ese texto es genérico: por sí solo no identifica el motivo ni demuestra que el SELECT esté mal escrito. Tampoco basta con que la tabla abra por USE para dar por comprobada la ruta SQL.
Para acotarlo sin cambiar DLL ni tocar datos reales:
Si rutas falla también como primera operación y clientes funciona, el siguiente mínimo útil sería la estructura de rutas y unas pocas filas inventadas que reproduzcan el fallo. Si solo falla después de abrir/cerrar las tablas, la secuencia previa pasa a ser el dato a investigar. Son comprobaciones para separar casos, no un arreglo confirmado; no he reproducido tu entorno.
Fuentes revisadas:
https://raw.githubusercontent.com/harbour/core/master/contrib/rddads/adsfunc.c
https://raw.githubusercontent.com/FiveTechSoft/OpenADS/v1.09.74/src/network/session.cpp
AdsCreateSQLStatement siempre retorna .t.
ACE DLL reports: 1.9a estoy usando openads-1.09.74-windows-x64.zip como servidor y openads-1.09.74-windows-x86.zip para el cliente
#include "common.ch"
#include "fivewin.ch"
#include "ads.ch"
#define USAR_CDX2
REQUEST ADS
REQUEST DBFCDX, DBFFPT
REQUEST HB_LANG_ESWIN, HB_CODEPAGE_ESWIN
EXTERNAL OrdKeyNo, OrdKeyCount, OrdKeyGoTo, OrdKeyRelPos
EXTERNAL AdsKeyNo, AdsKeyCount, AdsGetRelKeyPos, AdsSetRelKeyPos
PROCEDURE Main()
LOCAL cConnect := "tcp://127.0.0.1:6262//misapp/openads/datos_test/test.add"
LOCAL cUser := ""
LOCAL cPass := ""
LOCAL cError := ""
LOCAL hConn := 0
SET DECIMAL TO 4
SET EPOCH TO 1990
SET DATE BRIT
SET SOFTSEEK OFF
SET CENTURY ON
SET OPTIMIZE ON
SET CONFIRM ON
HB_LangSelect( "ESWIN" )
HB_SetCodePage( "ESWIN" )
? "ACE DLL reports:", AdsVersion()
AdsSetServerType( ADS_REMOTE_SERVER )
RddSetDefault( "ADS" )
AdsSetCharType( ADS_ANSI )
AdsRightsCheck( FALSE )
AdsLocking( FALSE )
#ifdef USAR_CDX
AdsSetFileType( ADS_CDX )
#else
AdsSetFileType( ADS_ADT )
#endif
IF ! AdsConnect60( cConnect, ADS_REMOTE_SERVER, cUser, cPass, 0, @hConn ) .OR. hConn == 0
AdsGetLastError( @cError )
?"Error de conexion o credenciales invalidas: ", cError
RETURN
ENDIF
? "Conexion y autenticacion exitosas con el diccionario!", "CONN:" + hb_ntos( hConn ), "Tipo:" + hb_ntos( AdsGetConnectionType( hConn ) )
DBSelectArea(0)
IF ADSCreateSQLStatement( "MYTMP", 2, hConn )
IF ADSExecuteSQLDirect( "SELECT * FROM rutas WHERE num_ciud=2;" )
DBSelectArea("MYTMP")
MYTMP->( xbrowse() )
MYTMP->( DBCloseArea() )
ELSE
AdsGetLastError( @cError )
?"Error de SQL: ", cError
ENDIF
ENDIF
close all
AdsDisconnect( hConn )
RETURNsi uso:
...
USE rutas VIA "ADS" SHARED NEW ALIAS "prueba
XBROWSER( "prueba" )
CLOSE ALL
...
y si en lugar de la tabla rutas, uso la tabla clientes, que tiene muchos registros es bastante grande unos 10mb
el USE clientes con xbrowse la muestra correctamente.
pero la consulta sql da el error que puse en mi primer mensaje
aca con el use... se muestra bien
aca el sql, este es el error
Carlos, la nueva captura cambia el diagnóstico: ahora sí se ha abierto MYTMP con las columnas del SELECT. En el código que muestras, ese browse solo se ejecuta cuando AdsExecuteSQLDirect devuelve .T.; por tanto, este intento ya no es el fallo de ejecución anterior, sino un resultado sin filas visibles.
La consulta nueva lleva WHERE num_ciud=2. En la parte visible de la captura de USE aparecen valores 10, 6, 5, 7, 9 y 11 para num_ciud, pero no 2. Eso no demuestra que no exista un 2 en el resto de la tabla, aunque sí explica por qué no podemos comparar ambas imágenes como si fueran la misma selección.
En esa misma copia y conexión fresca, compara ahora el SELECT de rutas sin WHERE con el que filtra num_ciud=10, valor que sí se ve en tu captura. Si devuelven filas, el cursor SQL está funcionando en ese ensayo y habrá que separar el caso anterior que devolvía 7200 de esta consulta filtrada. Si el SELECT sin WHERE sigue vacío mientras USE muestra registros, ese será el mínimo concreto a investigar.
Quedan anotados los ZIP v1.09.74 x64 para servidor y x86 para cliente, AdsVersion() = 1.9a y la creación del statement correcta. No doy por resuelto todavía el error anterior ni atribuyo la diferencia a CLOSE ALL sin una comparación equivalente.
...
DBSelectArea(0)
IF ADSCreateSQLStatement( "MYTMP", 2, hConn )
IF ADSExecuteSQLDirect( "SELECT * FROM rutas" )
DBSelectArea("MYTMP")
MYTMP->( xbrowse() )
MYTMP->( DBCloseArea() )
ELSE
AdsGetLastError( @cError )
?"Error de SQL: ", cError
ENDIF
ENDIF
....
Gracias, Carlos. Con el SELECT sin WHERE y esa captura ya no basta la explicación del filtro: MYTMP sigue sin mostrar filas. No lo doy por solucionado.
Antes de atribuirlo al motor SQL o al browse, falta distinguir un cursor realmente vacío de uno mal posicionado. En MYTMP, justo antes de llamar a xbrowse, recoge RecCount(), RecNo(), Bof() y Eof(); después haz GO TOP en esa misma área y comprueba de nuevo esos valores y si el browse muestra filas. Hazlo en la copia de pruebas, sin cambiar DLL ni datos.
Si el recuento es mayor que cero pero no aparecen filas, investigaremos la posición/lectura del cursor. Si devuelve cero, el siguiente paso será un caso mínimo con estructura y unas pocas filas inventadas que muestre la diferencia entre USE y ese SELECT en el mismo diccionario. No hace falta publicar la tabla real ni sus registros.
De momento tenemos confirmada la diferencia visible entre USE y SQL en tus capturas, pero todavía no su causa ni una corrección.
informacion
luego muestra los datos por un instante
y luego de un instance se muestra vacio
#include "common.ch"
#include "fivewin.ch"
#include "ads.ch"
#define USAR_CDX2
REQUEST ADS
REQUEST DBFCDX, DBFFPT
REQUEST HB_LANG_ESWIN, HB_CODEPAGE_ESWIN
EXTERNAL OrdKeyNo, OrdKeyCount, OrdKeyGoTo, OrdKeyRelPos
EXTERNAL AdsKeyNo, AdsKeyCount, AdsGetRelKeyPos, AdsSetRelKeyPos
PROCEDURE Main()
LOCAL cConnect := "tcp://127.0.0.1:6262//misapp/openads/datos_prueba/prueba.add"
LOCAL cUser := ""
LOCAL cPass := ""
LOCAL cError := ""
LOCAL hConn := 0
SET DECIMAL TO 4
SET EPOCH TO 1990
SET DATE BRIT
SET SOFTSEEK OFF
SET CENTURY ON
SET OPTIMIZE ON
SET CONFIRM ON
HB_LangSelect( "ESWIN" )
HB_SetCodePage( "ESWIN" )
? "ACE DLL reports:", AdsVersion()
AdsSetServerType( ADS_REMOTE_SERVER )
RddSetDefault( "ADS" )
AdsSetCharType( ADS_ANSI )
AdsRightsCheck( FALSE )
AdsLocking( FALSE )
#ifdef USAR_CDX
AdsSetFileType( ADS_CDX )
#else
AdsSetFileType( ADS_ADT )
#endif
IF ! AdsConnect60( cConnect, ADS_REMOTE_SERVER, cUser, cPass, 0, @hConn ) .OR. hConn == 0
AdsGetLastError( @cError )
?"Error de conexion o credenciales invalidas: ", cError
RETURN
ENDIF
? "Conexion y autenticacion exitosas con el diccionario!", "CONN:" + hb_ntos( hConn ), "Tipo:" + hb_ntos( AdsGetConnectionType( hConn ) )
DBSelectArea(0)
IF ADSCreateSQLStatement( "MYTMP", 2, hConn )
IF ADSExecuteSQLDirect( "SELECT * FROM rutas" )
DBSelectArea("MYTMP")
?alias(), RecCount(), RecNo(), Bof(), Eof()
go top
MYTMP->( xbrowse() )
MYTMP->( DBCloseArea() )
ELSE
AdsGetLastError( @cError )
?"Error de ADSExecuteSQLDirect: ", cError
ENDIF
ELSE
AdsGetLastError( @cError )
?"Error de ADSCreateSQLStatement: ", cError
ENDIF
close all
AdsDisconnect( hConn )
RETURNcabe señalar que con ads estas funciones han trabajado sin probemas.
siempre muestran los datos, es más tengo una lib que me facilita la vida con adsRunSQL, adsExecuteSQL, aca esta con lo básico.
salu2
Carlos, este dato sí acota el problema: antes del browse MYTMP tiene 31 registros, está en el registro 1 y BOF/EOF son .F. Además, tras GO TOP se ven las filas en tu captura. Por tanto, en este ensayo el SELECT ha devuelto datos; no estamos ante un resultado SQL vacío.
Lo que falta explicar es por qué, después de mostrarlos, el browse queda vacío. Las capturas no permiten distinguir todavía entre un cambio de posición/estado del cursor durante la navegación y un problema de refresco. Tampoco prueban que se hayan perdido registros.
Conservo esta secuencia como el caso a investigar: cursor con 31 registros, filas visibles al abrir y vista vacía después. No te pido repetir las pruebas anteriores ni cambiar DLL. El error 7200 inicial queda separado: estas capturas ya no muestran ese fallo de ejecución y aún no tenemos una causa ni una corrección confirmadas.
funcionando bien. con wbrowse.
DBSelectArea(0)
IF ADSCreateSQLStatement( "MYTMP", 2, hConn )
IF ADSExecuteSQLDirect( "SELECT * FROM rutas" )
DBSelectArea("MYTMP")
?alias(), rddname(), RecCount(), RecNo(), Bof(), Eof()
go top
//MYTMP->( xbrowse() )
MYTMP->( browse() )
MYTMP->( DBCloseArea() )
ELSE
AdsGetLastError( @cError )
?"Error de ADSExecuteSQLDirect: ", cError
ENDIF
ELSE
AdsGetLastError( @cError )
?"Error de ADSCreateSQLStatement: ", cError
ENDIF
ahora esta el problema con la tabla clientes, que con use se muestra bien, y luego falla con error