Salve,
non posso dirti quello che "devi" fare... ti posso dire quello che "io" richiedo...
utilizzando di base SQL Server, "io", "non accetto" codice come hai scritto tu, neanche se utilizzato tramite un command... nei framework che seguo, "tu" utilizzerai sempre e solo chiamate, sempre e solo tramite oggetti command, a stored procedures che il dba o altri abbiano gia' "autorizzato", valutato, ed ottimizzato... brutalmente, per capirci, cosa succede al tuo codice "se" il dba decide che la tua tabella
"INSERT INTO " & IniTbl & _
"([Numero],[Descrizione],[Famiglia]," & _
"[Iniziale],[Destinazione],[Percorso]," & _
"[Stato],[Start]) " & _
non sara' piu' una sola tabella ma verra' "normalizzata" ulteriormente, per problemi architetturali, per problemi di armonizzazione degli "schemas", per frammentazione o altro? tendenzialmente "tutto" il codice applicativo dovra' essere analizzato per per verificarne i punti di accesso ed escludere che nessuna istruzione DML che referenzi la tabella
[dbo].[pippo] sia ancora presente, visto che la tabella ora e' magari stata scomposta in
[production].[pippo_legacy] e [production].[pippo_dati_nuovi]... con chiamate a stored procedures, il dba puo' permettersi, a parita' di parametri di ingresso e sempre a parita' di result set finale, di modificare e quindi "astrarre" completamente la "sua" base dati dal "tuo" codice applicativo, senza "rompere" niente (ok, questo ovviamente e' un'affermazione molto forte )... ancora, tu potresti non sapere che la chiamata a "SELECT p.[x], p.[y], p.[z] FROM [dbo].[pippo] p WHERE p.[x] = @param" che tu esegui dinamicamente, nella stored procedure che la sostituisce e che tu sei chiamato ad usare, quest'anno il dba abbia deciso di aggiungere " .... OPTION (
OPTIMIZE FOR (@anno = 2019') ); " visto che, quest'anno e' il 2019, mentre l'anno prossimo probabilmente utilizzera' 2020, e tutto questo consente migliore riusabilita' dei piani di esecuzione con aumenti di performance ...
comprendo ovviamente che ad esempio tutti i "nuovi attrezzi" ORM siano bravi (piu' che bravi, a dire il vero) a scrivere codice dinamico, ma personalmente preferisco il "mio"
ed in ogni caso i punti di accesso, e quindi di failure, sono minori e piu' controllabili... con il "tuo" codice dinamico, non penso tu sappia in effetti dire "velocemente" quanti siano questi punti di accesso alla base dati, alla specifica tabella, o ancora allo specifico attributo... con restrizioni di uso alle sole stored procedures, la valutazione si risolve sicuramente molto piu' in fretta e coinvolgendo sicuramente meno persone nell'analisi...
ed altre motivazioni sono a sostegno di questa modalita'... come altre sono sicuramente contrarie.
ripeto pero'.... questa e' una guerra di religione e non voglio ovviamente convincere nessuno... c'e' chi e' milanista e chi no
polemica = off :D
saluti omnia
--
Andrea