MegaLab.it

Porca miseria che pazienza!! sto convertendo un programma che usava DAO Access in ADO Sql Server e sto sclerando!!
Qualcuno mi deve spiegare cosa diavolo c'è di standard nel linquaggio SQL!! Ogni database ha le sue "paroline magiche"!! Mah!

Sto facendo una funzione che fa il parse dell'istruzione SQL e la modifica per adattarla al database in uso; c'è qualcuno che ha già qualcosa di collaudato?

...ooops in effetti SQL non vuol dire Standard Query Language, ma Structured Query Language

http://it.wikipedia.org/wiki/Sql

...vado a studiare

Robby78 ha scritto:Porca miseria che pazienza!! sto convertendo un programma che usava DAO Access in ADO Sql Server e sto sclerando!!

Copione!

In effetti ne parlavamo giusto qualche giorno fa ed è proprio quello che sto facendo io e che probabilmente farò per i prossimi sei mesi, vista la complessità della cosa! Tra l'altro oltre al "dialetto" SQL ci sono anche le diverse sintassi proprie della tecnologia DAO rispetto ad ADO. Nelle applicazioni che sto passando io è stato fatto largo (larghissimo) uso di manipolazione campi e tabelle con i vari oggetti field, table ecc. ecc. e non ti dico convertire il tutto in istruzioni SQL che piacere

Comunque per restare in tema:

Sto facendo una funzione che fa il parse dell'istruzione SQL e la modifica per adattarla al database in uso; c'è qualcuno che ha già qualcosa di collaudato?

....no... io sto implementando tutto utilizzando le classi, in modo da modificare meno possibile sul software originale ed aggiungere uno "strato" in più che si interponga tra le vecchie istruzioni DAO e l'invio delle sql agli oggetti connection, ma per il momento è tutto "work in progress"

DilanDog ha scritto:Tra l'altro oltre al "dialetto" SQL ci sono anche le diverse sintassi proprie della tecnologia DAO rispetto ad ADO. Nelle applicazioni che sto passando io è stato fatto largo (larghissimo) uso di manipolazione campi e tabelle con i vari oggetti field, table ecc. ecc. e non ti dico convertire il tutto in istruzioni SQL che piacere

sisi, immagino! ma quello ci può anche stare... in effeti ADO è molto più lineare, con meno oggetti più funzionali: il prezzo da pagare per razionalizzare lo sviluppo fatto in DAO (a mio parere orrendo). Però cavolo, perché Now deve essere diverso da GetDate(), perché CDate deve diventare TO_Date in Oracle e Convert(DATETIME in sql server... che nocciole!!!!!!

DilanDog ha scritto:....no... io sto implementando tutto utilizzando le classi, in modo da modificare meno possibile sul software originale ed aggiungere uno "strato" in più che si interponga tra le vecchie istruzioni DAO e l'invio delle sql agli oggetti connection, ma per il momento è tutto "work in progress"

capisco... l'idea delle classi è buona, comunque preferisco "arare" tutti i vari oggetti dynaset, snapshot, table e chi più ne ha + ne metta in favore di semplici ADODB.Recordset e ADODB.connection.

In effetti non mi preoccupo tanto delle differenze tra DAO e ADO (mi sono messo l'anima in pace), quanto all'inutilità dei vari dialetti SQL...

In effetti non mi preoccupo tanto delle differenze tra DAO e ADO (mi sono messo l'anima in pace), quanto all'inutilità dei vari dialetti SQL...

Capito il problema...ed in effetti è strano che non esista già qualcosa in giro. Beh, visto che sei più avanti di me vorrà dire che mi ricorderò di questa discussione e della tua libreria ormai pronta e collaudata tra qualche mese quando mi ritroverò ad affrontare il discorso delle query

DilanDog ha scritto:

In effetti non mi preoccupo tanto delle differenze tra DAO e ADO (mi sono messo l'anima in pace), quanto all'inutilità dei vari dialetti SQL...

Capito il problema...ed in effetti è strano che non esista già qualcosa in giro. Beh, visto che sei più avanti di me vorrà dire che mi ricorderò di questa discussione e della tua libreria ormai pronta e collaudata tra qualche mese quando mi ritroverò ad affrontare il discorso delle query

heheehhe Vaaaaaaaaaaaaabene, Ooooooooooooooochei!

Beh veramente le funzioni basilari sono uguali su tutti i DB, quello che cambia di solito sono i Trigger (sempre se supportati..), la gestione dei permessi, e ovviamente le funzioni di libreria per la connessione al DB stesso..

atomik ha scritto:Beh veramente le funzioni basilari sono uguali su tutti i DB, quello che cambia di solito sono i Trigger (sempre se supportati..), la gestione dei permessi, e ovviamente le funzioni di libreria per la connessione al DB stesso..

non sono d'accordo, dai un'occhiata alle funzioni di manipolazione dei valori, o di funzioni particolari; ad esempio per ottenere la data attuale: Access=Now, SQL Server=GetDate(), Oracle=sysdate; in Oracle esite la tabella viruale "dual" per fare operazioni varie, negli altri no... ecc

Beh tu hai citato una delle cose che ognuno ha implementato a suo modo, ma quella funzione non fa' parte del set di istruzioni SQL di base.

SQL di base sono solo CREATE, DROP, INSERT, UPDATE, etc etc..

Poi non inserirei Access tra i DBMS, quello e' un caso anomalo che non vale la pena nemmeno citare.

atomik ha scritto:Beh tu hai citato una delle cose che ognuno ha implementato a suo modo, ma quella funzione non fa' parte del set di istruzioni SQL di base.

SQL di base sono solo CREATE, DROP, INSERT, UPDATE, etc etc..

Poi non inserirei Access tra i DBMS, quello e' un caso anomalo che non vale la pena nemmeno citare.

si, su questo siamo d'accordo, l'ho citato perché comunque per anni è stato il database più diffuso per piccole applicazioni di gestione; dove non c'è una necessità esagerata di salvaguardare i dati (es. applicazioni che lavorano su dati real-time), quindi capita spesso di trovare programmi che si basano su database MDB; non sempre c'è necessità di avere un database serio.
Riguardo alle funzioni che ho citato, sono necessarie in alcune operazioni di base; la maggior parte delle volte che si aggiorna un record ad esempio, si deve aggiornare la data di ultima modifica, e quindi entra in gioco il famoso GetDate, SysDate o Now... una bella rottura di scatole!! potevano includere anche queste istruzioni nel set di base!! ...beh pazienza.

Robby78 ha scritto:
[....] non sempre c'è necessità di avere un database serio.

A titolo di cronaca, purtroppo ci sono anche realtà in cui servirebbe un database serio e viene utilizzato mdb

DilanDog ha scritto:

Robby78 ha scritto:
[....] non sempre c'è necessità di avere un database serio.

A titolo di cronaca, purtroppo ci sono anche realtà in cui servirebbe un database serio e viene utilizzato mdb

hehehe quanto hai ragione!!! [SIG!]