[VB6] Differenze tra SQL (Access) e TSQL (SQL Server)

[matt_vb6]

Ciao a tutti ,
dopo un immenso e titanico lavoro di trasformazione da DAO a ADO su 560 finestre
durato quasi 1 anno e mezzo (...) mi imbatto in un altro lavoraccio .
Il linguaggio SQL non è compatibile con Sql Server .

Per ora l'unico metodo che sono riuscito a trovare è stato collegare le tabelle di Sql Server
ad Access e aprire con JET ... ma le prestazioni sono di gran lunga inferiori al normale .

Esiste un alternativa o mi tocca rimettere mano alle 560 finestre (cambio lavoro...) ?

Mi riferisco in particolare a :

WHERE NOMECAPO=TRUE ' non funziona in SqlServer il campo è bit e quindi true = 0
-IIF() ' DEVE DIVENTARE CASE WHEN .....
-SELECT NOMETABELLA.* ' a volte me la trasforma in TOP(100)
-UPDATE CON INNER JOIN - al contrario rispetto ad access (ma perchè ...)

p.s. ho solo 1.358.000 linee di codice ...

Grazie a tutti !

[gibra]

Perchè un database Access è nato per essere gestito dall'ambiente di lavoro MS Access.
Quindi include alcuni metodi che funzionano SOLO se utilizzate con MSAccess.

Alcune funzionano ANCHE in VB6 perchè sono proprie della libreria VBA, che in SQL SERVER ovviamente non esiste.
Anzi, oggi bisogna fare un distinguo: se si installa Microsoft Office 2010 alcune funzioni anche banali non 'funzionano' più, ad esempio Round() nelle query viene segnalata come NON TROVATA (invece c'è ancora, è lì, ma non funziona in VB6).
In pratica, se il cliente decide di passare a Office2010, e nel programma si sono utilizzate nelle query delle funzioni 'interne' di Access il programma potrebbe non funzionare più.

La tua affermazione:

Il linguaggio SQL non è compatibile con Sql Server.

non corrisponde al vero perchè stai confrontando pere con mele.
Access e SQL Server sono due cose completamente diverse.

Per cui è corretto affermare che il SQL di Access e le istruzioni/funzioni di Access non sono compatibili con SQL Server nella misura in cui queste sono proprie ed esclusive di Access, ma non vedo perchè ciò dovrebbe stupire...
Sarebbe come pretendere che SQL Server fosse compatibile con MySQL.
Per quale ragione dovrebbe esserlo?

Al contrario, se si usano istruzioni SQL del linguaggio standard SQL-ANSI 92 (ovvero NON proprietarie di Access) la stessa istruzione funziona su qualsiasi database.

Il SQL-ANSI 92 è la base del linguaggio SQL, poi ogni database può implementare (e di solito è così) un proprio dialetto (in SQL Server è il TSQL) che incrementa funzionalità non previste dal SQL-ANSI 92.
E' comunque vero che possono anche esservi dei casi in cui database di marche diverse hanno alcune limitazioni, ma sono relativamente poche e ben documentate.


Riguardo all'affermazione:

mi tocca rimettere mano alle 560 finestre

ciò significa che hai sparso le query per tutti i form dell'applicazione.
Questa è una modalità di programmazione vecchia, ma d'altronde se il programma è stato realizzato diversi anni fa è comprensibile, magari se realizzato da 'autodidatta' con poca esperienza.

Questo approccio è sbagliato perchè, come sta accadendo a te, rende necessario rivedere tutto il codice dell'applicazione.
Invece è neccessario separare l'accesso ai dati da quello che è l'UI (interfaccia utente).
Mi spiego in parole semplici: è quello che in gerco tecnico vengono definite le 'classi helper' ovvero quelle classi che 'raggruppano' tutte le istruzioni per l'accesso ai dati e si creano per due motivi principali:

1) Avere tutte le istruzioni in un unica classe, il che significa
a - codice più facile da manutenere
(ho aggiunto un campo? mi basta modificare il codice della classe, senza essere costretto ad andare 'a caccia per tutto il codice sorgente' perchè ovviamente non mi ricordo se devo aggiornare altre query).

b - Poter sfruttare le stesse funzioni, metodi e proprietà per tutto il progetto

2) Posso creare 'classi helper' diverse a seconda del database (SQL Server, Oracle, DB2, ...) con cui devo interfacciarmi;
oppure posso usare la stessa 'classe helper' creando diverse copie della stessa routine, ma predisposte per database diversi.

Concludendo, ogni migrazione è un'opportunità per crescere, perchè è ovvio che errori di progettazione commessi in passato (quando ancora non erano o non sembravano errori) oggi vengono 'al nodo'.
Ci siamo passati tutti, chi più chi meno; sta a noi scegliere se fare il 'salto' oppure no in funzione di valutazioni assolutamente soggettive che riguardano i costi, le risorse, la convenienza, ...
Ognuno deve fare i conti in casa propria.

Un po' come è accaduto quando da VB6 si è passato al .NET:
nonostante tutte le balle che ci hanno rifilato sulla facilità, compatibilità etc. etc. è stato (e sarà per chi deve ancora farlo) un 'salto nel buio'.
Ma anche questa è un'opportunità di crescita, ed alla fine la soddisfazione è impagabile.

Scusa se mi sono dilungato.

[matt_vb6]

Ciao Gibra ,
effettivamente il progetto ha una decina di anni e le query sono sparse dappertutto .
Il rammarico è che il Sql (di Access.. chiaramente) scopri nel momento del bisogno che non è pienamente compatibile con il TSQL ...

E io mi domando perchè hanno fatto una specie di dialetto per Access ...
Non era meglio mettere subito il CASE WHEN al posto di IIF ?
Oppure concatenare con + al posto di & ecc ecc ....

Io credo che ci siano molte applicazioni che richiedono un upgrade in un futuro ,
e cosa faccio ? Mentre aspetto che i database dei clienti crescano mi preoccupo di fare le query doppie ?

Perchè quello che va bene a TSQL non va bene ad Access e viceversa .

Il problema secondo me è da chi arrivano questi programmi ... la cara Microsoft poteva anche fare in modo che Access funzionasse con il TSQL e invece ... NO !
Cosa gli cambiava ?

E io mi devo fare il famoso milione di righe di codice a mano

Spero solo sia l'ultima volta ....

Ma vorrei sapere da qualche "passante" ... sono l'unico ad avere questo problema nella migrazione da Access a SqlServer ? Tutti gli altri avevano già previsto le doppie query ?


P.s. senza polemica nè ??? anzi ho qualche routine utile a questo cambiamento , se qualcuno ci sta sbattendo la testa lo aiuto !!!