Utilizzo quotidianamente la suite Apex con estremo successo, partendo da Apex Sql Edit, che considero di gran lunga il migliore dei prodotti che fanno parte di Apex Studio. Non sto qui a sottolinearne i pregi, perchè sono sinceramente davvero tanti e sarebbe troppo lungo e noioso elencarli. Magari lo farò una prossima volta, in un prossimo post.
Non sono invece d'accordo sul criterio/algoritmo che Apex Sql Diff utilizza per capire quando due oggetti del nostro database sono diversi. Questo tool si occupa di rilevare le differenze (sia di struttura che di dati) di due database, generando alla fine uno script SQL più o meno lungo e complesso capace di sincronizzare i database e di portarli così allo stesso stato. Si tratta praticamente di un wizard, che ci chiede quali sono i due database da confrontare, quali oggetti elaborare (tables, views, rules, function, etc.) e così via. Per capire quando due oggetti sono differenti, Apex Sql Diff chiede gli script DDL degli oggetti source e destination, facendone un confronto. Ritengo che sia estremamente superficiale, perchè a me accade che questo script...
ALTER TABLE [dbo].[OOOOOO_OOOOOOOOOO]
ADD
DEFAULT (0) FOR [IMPACT]
GO
...è diverso dal seguente...
ALTER TABLE [dbo].[OOOOOO_OOOOOOOOOO]
ADD
DEFAULT ((0)) FOR [IMPACT]
GO
...cosa che non è affatto vera. Una parentesi aperta o chiusa in più non cambia la sostanza delle cose. E' scritta o impaginata diversamente, ma la tabella risultante è esattamente la stessa. Questo comportamento non è di poco conto, perchè in alcuni casi si scatena una reazione a catena, secondo la quale sincronizzando una banale tabella, in realtà vengono trovati oggetti dipendenti che risultano modificati anche quando non è vero! Mi è capitato giusto qualche minuto fa: avevo due viste, su due tabelle diverse. Una di queste tabelle veniva utilizzata da una stored-procedure, la quale veniva chiamata da un'altra, e da un'altra ancora. Morale: per fare l'ALTER COLUMN di un campo è saltato fuori uno script lunghissimo, che tra le altre cose droppava key, primary key e foreign key. Assolutamente inconcepibile!
Effettivamente, questo è quasi comprensibile nelle stored-procedure, ma io (che l'ho fatto in passato) avrei fatto qualcosa di più raffinato, tipo ciclare su ogni field in tabella, controllare nomi, tipi, lunghezza e via dicendo. In passato mi ero scritto un'utility in VB6 piccola, veloce e funzionale, che faceva il suo bravo lavoro, ma non arrivava al punto di generare gli script.