Gambas-it

Archivi (sola lettura) => Programmazione (Gambas 2) => Topic aperto da: Mario - 16 Ottobre 2008, 12:43:11

Titolo: Utilizzo diretto di SQL
Inserito da: Mario - 16 Ottobre 2008, 12:43:11
Ehilà!
Tutto bene? :)

Una cosa che non riesco a far funzionare (probabile problema di AMD64...) è l'ODBC verso gli AS/400 all'interno di Gambas.
Trafficando però ho visto che i comandi SQL dati in isql funzionano normalmente, per cui mi sorge la domanda: è possibile utilizzare chiamate dirette a SQL dentro Gambas, evitando l'uso diretto dell'ODBC?

:)

Ciau

Mario
Titolo: Re: Utilizzo diretto di SQL
Inserito da: md9327 - 16 Ottobre 2008, 14:38:49
Come al solito ti esibisci sempre con domande difficili... :-)

Scherzo!

Da quello che ho inteso dal tuo post, sembra che tu ti debba collegare ad un database Firebird; "isql" assomiglia moltissimo al programma a riga di comandi di questo db, ma forse sbaglio.

Ad ogni modo, se invece il db è proprio quello che penso, allora la risposta è NI, ovvero gambas ha i driver per connettersi direttamente a Firebird; sul come poi attivare questi driver, e le relative librerie, non sò come aiutarti, dato che ci ho provato sulla base di un'altra richiesta di un'altro utente del forum, ma senza risultato.

Poi, se tutto funziona per AS/400 non sò, anche se il collegamento non credo dipenda dal tipo di sistema, altrimenti gli standard TCP/IP che ci stanno a fare? :-)
Titolo: Re: Utilizzo diretto di SQL
Inserito da: Mario - 16 Ottobre 2008, 16:20:38
EH eh, le domande me le studio di notte :)

Allora, ti spiego: ho il driver ODBC di mamma IBM correttamente settato, e questo lo so perché lanciando isql su questo collegamento, posso lanciare i comandi classici ottenendo risposte corrette.
Purtroppo l'ODBC di iSeries Access, in ambiente Gambas, non funziona, nel senso che quando lo lancio mi da un errore #11, quello generico.
HO anche provato a chiedere a Lui (Benoit, da non nominare invano ;) ), che non ha trovato una soluzione.
Io penso che sia un problema di AMD64 (la mia macchina è carrozzata così) per cui c'è qualche piccola idiosincrasia a livello di .so, che magari lui si aspetta a 32 bit e invece trova a 64 bit... non che sia grave, ma quando piglio il prossimo computer lo prendo con un 8088!

Visto che isql funziona mi chiedevo se era possibile bypassare l'utilizzo dell'ODBC utilizzando direttamente i comandi SQL.

Nel sistema AS/400 si fa questa cosa nell'RPG (o Cobol) embedded: in pratica, all'interno del sorgente si inseriscono dei comandi SQL, che un precompilatore traduce in chiamate a delle API esterne.
In questi ambiti su utilizzano i CURSORI, che sono praticamente dei file temporanei che contengono il risultato del comando SQL, e che possono essere utilizzati in lettura, anche casuale, con altri comandi (FETCH NEXT, eccetera...)
Speravo che anche in Gambas fosse possibile, ma mi sa che dovrò aspettare di avere un 386... :(
Titolo: Re: Utilizzo diretto di SQL
Inserito da: Mario - 16 Ottobre 2008, 16:21:53
A PROPOSITO!

md9327, devo farti le mie congratulazioni per il prodotto che hai realizzato e che è stato inserito nel repository di UBuntu!
Ho visto solo qualche immagine ma mi sembra estremamente interessante...
chissà se un giorno potremo collegarlo, via ODBC, per poter gestire il DB2 dell'AS/400?! :D
Titolo: Re: Utilizzo diretto di SQL
Inserito da: md9327 - 16 Ottobre 2008, 19:04:43
E' più sicuro uno Z80... :-)

Il problema è che servono delle librerie apposite, come del resto fanno ODBC e qualsiasi altra scatola nera...
Dato che non si tratta neppure di Firebird, allora non c'è uscita, perchè gambas si aggancia solo ad un set di librerie, e quindi di tipi di database: FireBird, MySQL, PostgreSQL, SQLite e ODBC.
Visto che il tuo database non è tra questi, allora non resta che l'alternativa ODBC, ma dato che non ti funzia, allora qui ci fermiamo.
Ci si può anche inventare salti mortali tripli e carpiati, ma certo la cosa non è così immediata; potresti gestire una specie di collegamento tra il programma gambas e isql, ma certo il discorso sarebbe abbastanza oneroso... Però, e dico però, il giochetto potrebbe andare, e sarebbe molto simile ad un processo a tre livelli, nel quale in mezzo c'è una sorta di scatola nera che si occupa di far da tramite tra i due programmi (una specie di quello che fà Tuxido, per far un esempio...). Questo però comporterebbe la creazione di una serie di protocolli di comunicazione per lo scambio dei dati, che isql rileverebbe direttamente dal database, ma che fornirebbe al programma gambas sotto forma di buffer ascii. Il discorso potrebbe anche essere utile a livello di sicurezza, dato che potresti agire su questa scatolina nera, ma sicuramente tutta la logica comporta un bel grosso lavorone!
Titolo: Re: Utilizzo diretto di SQL
Inserito da: milio - 16 Ottobre 2008, 20:01:17
Non riesci a passare il codice sql con la funzione Connection.Exec(query) ?
Titolo: Re: Utilizzo diretto di SQL
Inserito da: md9327 - 17 Ottobre 2008, 00:37:25
No, perchè la Connection ha bisogno di connettersi al db tramite un driver, tra quelli che ti ho elencato.

Il giochetto non si basa solo su stringhe sql, ma sul le modalità di connessione al singolo database, che varia da uno all'altro.

In generale sappiamo che un motore rdbms (db) funziona per gestire dati al suo interno, ognuno a suo modo e con particolarità diverse dagli altri; per poter gestire questi dati, il db ha necessità di collegamenti da/verso l'esterno, e per far questo vengono creati appositi driver, ovvero delle scatolette nere, che hanno il compito di aprire delle porte e di gestire la comunicazione tramite diversi protocolli, che non sono tutti uguali.
Una volta aperta la porta, e stabilite le modalità di scambio con l'esterno, è necessario che un sistema implementi tutte le logiche necessarie per interfacciarsi a questa scatola nera.
Con l'arrivo del web, e delle connessioni via rete, questa logica di connessione si è ampliata, aggiungendo ulteriori scatole nere che permettono il colloquio con il db tramite altri sistemi di comunicazione (vedi tci/ip, ecc.).
Il fato è che comunque, la primaria scatoletta nera (quella che apre la porta, tanto per intenderci) è sempre uguale (a parte le diversità di db e di versione), e quindi è necessario comunque stabilire la comunicazione tramite i protocolli prestabiliti dalla scatola.
Per evitare che ogni nuovo programma, che acceda ad un db, implementi ogni volta il suo apposito driver di collegamento, si utilizzano librerie esterne, ovvero altre scatolette nere che unificano e rendono più malleabile la gestione di un programma.
In assenza di queste scatolette (librerie) hai due alternative: costruirle ex-novo, ma in questo caso devi avere una perfetta conoscenza dei protocolli usati e di tutte le varianti del caso, oppure impiccarti al primo albero basso... :-)
Le librerie su cui si appoggia Gambas, sono librerie fornite ovviamente dai creatori di questi db, e nessuno si sogna di farne di nuove, per ovvi motivi...
Quindi, per concludere, non serve passare stringhe a chi non sà con cosa ha a che fare; Connection è un oggetto che ha bisogno di sapere a quale libreria rivolgersi per passare dati, e per qualsiasi altra forma di comunicazione come, ad esempio, se il db li ha memorizzati o meno, oppure addirittura gestire un cursore.

Spero di aver chiarito il concetto... :-)

Riguardo a pgDesigner, ti ringrazio, ma per il momento nessuna previsione sull'ODBC... Attualmente sono già troppo impegnato ad implementare MySQL e SQLite, e non è cosa facile.
La connessione ODBC poi è un tipo di connessione considerata generica, perchè proprio per la sua generalizzazione non permette di sfruttare appieno di tutte le potenzialità che il database offre.
Io lavoro giornalmente con Oracle, e la potenza di questo dbms può essere sfruttata solo attraverso i suoi driver proprietari, difficilmente qualcuno usa alternative come l'ODBC.
Ad ogni modo anche odbc ha bisogno di driver, e sono molti che non se ne rendono conto... Il suo scopo reale è quello di rendere più standard possibile le connessioni ad un db, ovviamente limitandone le caratterizzazioni di ognuno.

Vabbè, ora mi fermo, che ho finito l'inchiostro... :-)
Titolo: Re: Utilizzo diretto di SQL
Inserito da: Mario - 17 Ottobre 2008, 10:39:59
Be' quando ho scoperto che ai dati iSeries (allora si parlava ancora di AS/400) si poteva accedere anche dal PC mediante questo misterioso ODBC, sono impazzito!
Considera che una 'ndicina di anni fa l'installazione su un PC di un emulatore 5250 richiedeva due ore buone, tre minidischi da 5 pollici (!!!) e una riserva di bestemmie formato famiglia allargata! :)
Quindi le possibilità che ci sono adesso sono meravigliose!

In effetti l'idea di sfruttare l'isql per fare le chiamate che interessano e poi intercettare il risultato non è poi così peregrina: in fondo o quello o niente e dalle nostre parti (Torino) si dice "Pì che tost a l'è mei pitost", come dire che meglio avere poco che NON avere il meglio ;)
Titolo: Re: Utilizzo diretto di SQL
Inserito da: md9327 - 17 Ottobre 2008, 12:22:16
'ndicina di anni fa dici? Hai paura di dire la tua età per caso ? :-)

Belli i 5 pollici, ci si sventolava bene durante l'estate, certo che gli 8" erano meglio, facevano più vento, però andavano bene lo stesso... :-)

Riguardo all'uso di isql, non è cosa nuova, come ti avevo già accennato, solo che metterla in piedi non è affare semplice.
Se hai in mente di farlo, ti auguro buona fortuna, però potrebbe essere un progetto interessante, in particolare per il fatto che trattasi di ambiente AS400.
Titolo: Re: Utilizzo diretto di SQL
Inserito da: Mario - 17 Ottobre 2008, 14:53:11
Età? Ah, ma è facile: sono del 1963, QUINDI ho 39 anni... :D

(non perdere il tempo a fare il calcolo, ho controllato... ho fatto un programmino in Gambas...)
Titolo: Re: Utilizzo diretto di SQL
Inserito da: ccc - 17 Ottobre 2008, 16:35:44
AS/400? COBOL? ...oh santa cleopatra...

Ci lavorava una mia ex, poi l'hanno messa a lavorare in ASP e quindi l'ho lasciata: va bene usare sistemi proprietari, ma fino a un certo punto. (Scherzo, i motivi sono altri, ma scrivendo questa battuta ho riso molto e spero altrettanto di voi :lol: )

Sono d'accordissimo sia sull'8088, sia sullo Z80, purchè l'altoparlante di sistema sia in buone condizioni  :-D (NB: anche scrivendo questo ho riso molto)

Deliri a parte, overhill, io di quei sistemi non so niente ma chissà che qui non trovi qualcosa che ti possa aiutare:

http://picosoft.it/products.htm
Titolo: Re: Utilizzo diretto di SQL
Inserito da: Mario - 17 Ottobre 2008, 20:44:07
Eh eh eh, interessante, molto :)
I sistemi come l'AS/400 (iSeries) sono stati dati per morti un sacco di volte, e ogni volta hanno trovato una nuova vita, per cui ben vengano le Cassandre :)
E poi queste macchine hanno diversi vantaggi: hanno una marea di servizi integrati nel sistema operativo (tcp/ip, http, dns, ntp, sna, voip, eccetera) quindi senza costi aggiuntivi; hanno il DB2 che è integrato e quindi non va comprato a parte (tipo Access di M$); hanno il supporto nativo a SQL e tutto quello che ci gira intorno (tipo le Stored Procedure); e soprattutto sono molto diffusi e poco conosciuti, per cui chi, come me, "gli da del tu", ha lavoro assicurato per un bel po' di anni... :D
Titolo: Re: Utilizzo diretto di SQL
Inserito da: ccc - 17 Ottobre 2008, 21:28:38
Mi fa piacere, e sono convinto che da un punto di vista tecnico mi piacerebbero un sacco... però sono allergico a tutto ciò che non è software libero  :evil:

In mezzo a tutte quelle diavolerie hai trovato qualcosa che possa risolvere il tuo problema?
Titolo: Re: Utilizzo diretto di SQL
Inserito da: Mario - 17 Ottobre 2008, 21:39:47
Per adesso no, ma sto imparando alcuni prodotti nuovi dell'AS/400 e non ho molto tempo... :)
Però ho una macchina non AMD64 e quindi posso provare lì se funziona o meno.
Titolo: Re: Utilizzo diretto di SQL
Inserito da: g.paolo - 18 Ottobre 2008, 09:05:38
Ti ricordo overhill, se non avessi avuto modo di saperlo, che gli AMD 64 funzionano comunque con versioni di linux e gambas a 32 bit. Io che ho avuto sempre AMD non mi sono mai azzardato a metter su sistemi a 64bit per non incorrere poi in qualche problema. All'inizio gambas c'era solo a 32bit e pertanto l'unico modo di usarlo senza problemi di sorta era quello di farlo andare sul 32bit.
Penso che per il 64bit serva ancora un bel po di tempo per renderlo affidabile come il 32bit e  non può certo essere diverso visto che il sistema è relativamente molto giovane!
Titolo: Re: Utilizzo diretto di SQL
Inserito da: Mario - 18 Ottobre 2008, 10:08:12
Be', sei fai un "file" sui file .so nelle rispettive cartelle a volte trovi oggetti a 64 bit, o comunque non riconosciuti dai programmi nati a 32 bit.
Quando ho un attimo ti posto il risultato :)
Sinceramente il perché non lo so, ma a volte mi capita di non avere "fortuna" con certi programmi e non riuscire a installarli sulla macchina di produzione (quella che uso adesso), mentre su altre che sono 386 va benissimo...
Titolo: Re: Utilizzo diretto di SQL
Inserito da: md9327 - 18 Ottobre 2008, 10:55:44
In realtà, Linux è super nei sistemi a 64 bit, il problema è legato solo ai programmi; alcuni stanno subendo parecchi ritardi nell'adattamento.

Anche io non ho mai messo mano ai 64 nei miei sistemi, proprio per questi motivi; inoltre il consumo di risorse è maggiore, anche se la velocità è un bel compromesso, ma per questo è necessario che giri tutto a 64.

Ho potuto vedere il comportamento di una distro linux su un sistema multiprocessore 64bit, non i dual o i quad core, e devo dire che le prestazioni spaventano, al contrario di altri sistemi operativi (ovviamente tirando fuori Unix, anche se in qualche caso Linux ha un qualcosina in più...).

Per i miei computer ho sempre ritenuto più affidabile e più standard il processore Intel, rispetto ad AMD; in effetti qualche tempo fà la differenza era evidente, forse oggi non lo è più così tanto, ma comunque nelle caratteristiche che forniscono per AMD non vedo ancora parametri stabiliti, ovvero si comportano in modo diverso a seconda delle situazioni, e questo a me pare strano.

Comunque, sono due processori molto potenti, ovviamente discorso a parte per xeon e similari...
Titolo: Re: Utilizzo diretto di SQL
Inserito da: Mario - 18 Ottobre 2008, 17:35:50
Eccomi :)

Guardate per esempio questi due file che hanno lo stesso nome ma si trovano in directory diverse, la lib32 e la lib64

in lib64
Codice: [Seleziona]
file libasound.so.2.0.0 
libasound.so.2.0.0: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), stripped


in lib32
Codice: [Seleziona]
file libasound.so.2.0.0 
libasound.so.2.0.0: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), stripped


Il grosso problema è sui programmi che puntano a una libreria come quella e si aspettano di trovare il file per i 32bit, trovando invece l'altro...
Ovviamente si può bypassare il problema creando ambienti di esecuzione con la corretta lista di librerie, ma non sempre è facile e a volte non è proprio possibile.
Titolo: Re: Utilizzo diretto di SQL
Inserito da: md9327 - 19 Ottobre 2008, 11:57:17
Il voler integrare sullo stesso sistema, due ambienti 32 e 64 bit è, secondo me, una forzatura, che può portare a dei bei casini...
E' come voler unificare un windoz con linux... sono due cose completamente separate, e funzionanti in maniera completamente diversa; stessa cosa per i 32/64 bit, a meno che non venga creata una struttura tale da renderli separati e al contempo accessibili dai diversi programmi.

Ma anche se fosse, il problema è che tutti i programmi dovrebbero seguire strettamente questa logica, ma al momento c'è troppa confusione al riguardo, e questo è un periodo di transizione, e molte persone prendono sotto gamba il problema.

Il mio pensiero è che, o si decide per 32 o per 64, e poi si continua su quella strada; il cambiamento in corsa può causare grossi problemi.
Decidere per 64bit al momento, vuol dire intraprendere un discorso più orientato all'avere un sistema più prestazionale, e orientato generalmente a fare da server.
Per chi, invece, usa il pc come strumento di lavoro, di studio o per sviluppo, non ha la necessità impellente di un supercomputer con un consumo doppio di risorse, e su cui molti programmi ancora non girano... a meno di non essere spinti a seguire anche qui la moda del momento...
Titolo: Re: Utilizzo diretto di SQL
Inserito da: Mario - 20 Ottobre 2008, 09:48:24
Che poi, volendo essere pignoli, con le macchine intel 32bit che ci sono in giro adesso (dual core, quad core, si parla anche di otto core, ma non so come li chiameranno: otta core? :-D ), e ram da 4 Gb, penso che nessuno possa dire che una workstation sia "lenta"... :-)
Titolo: Re: Utilizzo diretto di SQL
Inserito da: md9327 - 20 Ottobre 2008, 11:33:08
Bè, la velocità non è che dipenda poi solo dal processore, anzi, diciamo che se questo non è ben supportato, tanto vale metterci un 386...

Ormai credo che nessuno si preoccupi più di sviluppare programmi, tenendo conto delle possibili risorse a disposizione; con tutte le possibilità offerte oggi dal mercato hardware, metter sù un sistema mediamente potente, non "sembra" più un problema.
A questo punto, i programmi se ne fregano assolutamente, e per fare le stesse cose di qualche anno fà, richiedono sempre più risorse (processore, memoria, dischi, ecc...).

La potenza di calcolo di questi ultimi processori (io per esempio ho un quad-core), è mostruosa ma...
Tempo fà mi sono divertito a far girare due programmi di elaborazione video, su due dei miei pc, di cui un 486 800Mhz 512Mbyte ram e sistema dischi scsii, e l'altro un dual core 2GHz 2Gbyte ram e dischi sataII... bè, ti dirò che la differenza non è stata poi molta, il nuovo pc ha terminato un minuto prima (dopo 30minuti di elaborazione)...
L'unica cosa che posso dirti su questo test, è che il 486 aveva uan struttura hardware che supportava il processore oltre 80%, diversamente dal dual-core che, seppur di marca, si perdeva nei meandri dei colli di bottiglia del sistema.

Oviamente questo mio esempio è solo tanto per parlare, ma dà un'idea della situazione odierna...
Diciamo che i processori hanno raggiunto, come dicevo pocanzi, potenze esagerate, ma poi il resto che fà? Che ci facciamo di 8core, se poi il software non li prevede? Il processore che fà, si diverte a passarsi i dati da un core e l'altro? A che serve elaborare gigabyte di dati in un secondo, se poi ci vuole mezz'ora per salvarli su disco?

...così, tanto per parlare...
Titolo: Re: Utilizzo diretto di SQL
Inserito da: ccc - 20 Ottobre 2008, 12:08:25
Sono felice che qualcun altro oltre a me pensi che questa situazione sia assurda. Io ho un Pentium 3. Dopo l'ultimo aggiornamento del kernel, il mio computer si riavvia o si spegne (sceglie casualmente una di queste due azioni) dopo 5 minuti di inattività, o di attività di cui non tiene conto (un click su una cartella non è un'attività). Cambiare le impostazioni del risparmio energetico non influenza questa sua simpatica abitudine. Ci ho messo diverso tempo a capire che era colpa del nuovo kernel: nella mia ingenuità non avrei mai creduto possibile che àLinux avrebbe introdotto un bug del genere, eppure non c'è altra spiegazione, e la dimostrazione è che usando il kernel vecchio il bug scompare.

Considerazione I: qualche anno fa si diceva che per chi ha un computer vecchio era molto meglio usare GNU/Linux anzichè Windows; oggi è il contrario.

Avete presente Balazar? E' un giochino. Niente di particolare, è nei repo di Ubuntu e Debian, ha una grafica 3D nettamente inferiore a quella della maggior parte dei giochi scritti per 486. Chi avesse dei dubbi lo provi e poi si vada a rivedere, per esempio, Doom. Bene, vi informo che su un Pentium 3 Balazaar non è utilizzabile.

Considerazione II: i requisiti di sistema si basano su quanto è vecchio un processore al momento in cui è stato scritto il programma e non hanno niente a che vedere con la sua potenza. Se ne fossi in grado, riscriverei un programma per 8086, con le stesse funzionalità, compilandolo su un qualsiasi supercomputer IBM. Sono convinto che sui modelli che usciranno fra pochissimi anni (5 anni?) tale programma non funzionerebbe o risulterebbe troppo lento per essere utilizzato.

Tornando ai 32/64 bit nello specifico, sarò un sempliciotto, o magari avrò provato i 64 bit sui computer sbagliati... fatto sta che non vedo differenza. Del resto, non so se qualcuno si ricorda l'Itanium. Era molto più lento dei computer della stessa "epoca" a 32 bit e Intel venne definita con molti aggettivi poco affettuosi. Se il buongiorno si vede dal mattino...

La differenza tra i 32 e i 64 però c'è ed è quella di cui si è parlato finora: la compatibilità. Allora io dico: forse inizialmente lo scopo dei 64 bit era la velocità, e se fosse rimasto lo scopo principale per tutti questi anni significherebbe che i dirigenti Intel e AMD sono dei cretini che hanno sperperato miliardi su miliardi per ottenere un risultato risibile. Se fosse così però chiunque sarebbe in grado di mettere su un'azienda e superarli nel giro di 2 settimane, cosa che non è ancora successa. Allora lo scopo dei 64 bit non sarà semplicemente obbligarci ad aggiornare hardware e software che altrimenti avremmo potuto non aggiornare per anni e anni e anni e anni a venire? Del resto, è dall'epoca del 486 che un aggiornamento dell'hardware non ha nessuna utilità per l'utente domestico se non migliorare la compatibilità con i nuovi software...
Titolo: Re: Utilizzo diretto di SQL
Inserito da: md9327 - 20 Ottobre 2008, 14:39:58
Bè, quando ero piccolino, sperimentavo con l'elettronica, e poi con i pc, che mi autocostruivo e che ancora adesso mi assemblo da solo, scegliendo ogni singolo pezzetto hardware. Questo per dire, che un pò ne capisco, e che con gli anni ho incrementato abbastanza le mie conoscenze, da poter affermare quello che ho scritto.

Ma a parte questo, non credo al discorso tra kernel linux o windoz, ma sicuramente credo che tutti i sistemi operativi si adattano e si evolvono attorno all'hardware; uniformandosi a questa situazione, tengono tutti ad abbandonare le compatiblità precedenti, a favore di miglioramenti per i nuovi supporti. Questo sottintende che è sicuramente probabile che si verifichino incampitibilità con vecchi hardware, tanto sono pochi che ancora lo usano, per cui a chi frega di continuarne lo sviluppo o di manutenere quello esistente?
Ad oggi non penso ci siano ancora persone che usando i dischi analogici di decenni fà, e tra qualche anno ci dimenticheremo i quelli IDE, ed ancora tra qualche decennio esisteranno nuovi sistemi che soppianteranno i precedenti, e così via. E' ovvio pensare che questo tipo di evoluzione, non possa mantenere a lungo compatibilità di sistemi che ormai sono estinti.

Però, rispetto alla II, devo darti conferma che il fondamento vero su cui si basano i cambiamenti, ovvero la reale spinta morale, non è l'evoluzione e il miglioramento, bensì il vile denaro. Il fatto che ogni due mesi tocca cambiare telefonino (è un esempio, ma reale), perchè quello nuovo ha un pelo in più che lo fà diventare di tecnologia superiore, e che comunque si sà che è già possibile costruire microcomputer che già fanno tutto quello che i produttori ci stanno propinando, a goccia a goccia, è già possibile farlo, ma che sarebbe molto poco economico... bè, dire che è una cosa schifosa è dire ancora nulla...

...

me è tanto per parlare, no?
Titolo: Re: Utilizzo diretto di SQL
Inserito da: milio - 10 Novembre 2008, 20:04:30
Mi intrometto nella discussione per segnalare che ho avuto lo stesso problema.
Ho da poco aggiornato il mio pc (con processore AMD 64) alla versione di kubuntu 8.10 64 bit ed installato i relativi driver odbc per mssql (freetds) e firebird. Ebbene con isql funziona tutto perfettamente ma con gambas si mi apre la connessione ma al momento di passargli l'istruzione con la function .exec mi da l'errore che ha dato a overhill.
Avete per caso notizie fresche per questo baco?