SQL Server, Access e affini.
Ogni tanto bisogna lavorare anche con i dati ... anzi diciamo che il più delle volte si lavora con i dati che devono essere memorizzati, quindi saper mettere le mani su un DB Relazionale è sicuramente cosa buona e giusta.
Data la mia recente esperienza di perdita di tempo con problemi legati alle User Instance di SQL Express mi sono preso la briga di cercare di spiegare al meglio cosa mi è successo e cosa sono queste User Instance, così che se almeno qualcuno incappa nel mio stesso problema, non perde come me ore preziose di tempo a cercare di risolvere il problema.
L'articolo è pubblicato qui.
Beh, fino a questa mattina avrei detto impossibile. E
questo dimostra quanto ci sia sempre da imparare.
Non sò se è una caratteristica di Access 2003, o solo pigrizia mia che non ho
mai spulciato l'help fino in fondo. Ma quelle volte che ho provato a farlo, ne
sono uscito sempre sconfitto e rassegnato al fatto che non si potesse ottenere
un risultato simile in Access.
E' evidente che mi sbagliavo. Il sistema c'è, ed è anche abbastanza idiota
(come non averci pensato prima??)
Aprite acces, create una tabella, aprite lo schema delle relazioni, quindi
aggiungete la tabella che vi serve due volte,...
Se utilizzando Access vi doveste imbattere nella
necessità di aggiornare una tabella massicciamente, avendo come prerequisito
quello di far collimare gli ID della tabella di origine con quelli della tabella
di destinazione, visto che:
1) la sintassi SQL di Access è leggermente diversa da quella di SQL
Server2) l'SQL di Access non supporta l'update con le subquery (o per lo
meno nella fretta non sono riuscito a farla funzionare)
Ecco una soluzione rapida ed indolore con la JOIN stile SQL Server.
UPDATE Tabella1 t1, Tabella2 t2 SET T1.campo = t2.campoWHERE
t1.ID = t2.ID;
I provider che sono restii a 2005 Express, con
questo prodotto chiamato VistaDB forse non avranno problemi.
Onestamente non ho verificato fino in fondo la cosa, nemmeno scaricato una
trial, ma se quella parolina embedded sta per "non devo installare nulla e non
devo avere security particolari", beh direi che visti i costi la cosa è
decisamente proponibile.
Se avrò tempo verificherò meglio, se qualcuno ha informazioni, dica pure che
mi interessa.
Avere un quadro chiaro della situazione, sapere quanti e
quali tabelle sono presenti, che relazioni ci sono, che tipo sono non è una cosa
che si può sottovalutare in nessun progetto, anche il più piccolo.
Quando poi gli strumenti a disposizione ti consentono di fare reverse
engineering da una base dati per ricavarne la struttura e poter replicare su di
un altro database, scrivere automaticamente query senza scervellarti ecc. ecc,
allora lo strumento integrato forse può passare in secondo piano.
Nulla a togliere alla capacità grafica dei diagrammi generati da SQL Server,
ma lo strumento si ferma appunto solo ai diagrammi e...
Ok, diciamo che questa soluzione l'ho scritta nel 2001,
all'epoca non facevo uso di blogs, quindi me la sono tenuta per me e per qualche
- forse - post negli apposti NG, ma nulla di più.Oggi stavo mettendo le mani
su di un mezzo programmino che mi sto scrivendo per uso interno, e cercavo un
sistema elegante per sapere se la mia Identity Column con la prossima insert mi
sfora il valore massimo consentito. Beh, gira che rigira, o ho cercato male io o
effettivamente nulla di più elegante non ci sta.Pure cercando nel mio
account di SQL Magazine non...