Newsgroup: it.comp.lang.visual-basic
Titolo: Query uniche? O tabelle temporanee?

Ragazzi vi chiedo un consiglio...
Chi ha esperienza nell'uso dei DB, cosa mi consiglia fra creare query 
grosse e uniche o usare tabelle temporanee create in run-time da 
cancellare a fine dei lavori?
Siccome creo dei report al volo, mi scoccia dover usare tabelle 
temporanee... anche perchè se in quei pochi secondi qualcun altro decide 
di fare delle stampe, potrebbe crashare il programma perchè si cerca di 
creare la stessa tabella (che già esiste).
Per rimediare creo delle tabelle che si chiamano TempXXX (con XXX un 
numero casuale con tanto di controllo sull'esistenza della tabella con 
quel nome), le riempio con dei dati (man mano faccio vari join fra la 
tabella temporanea e quelle del db) e poi alla fine la apro per 
visualizzare i risultati.
Ma l'uso delle tabelle temporanee mi infastidisce...
Non si sa mai... durante i calcoli potrebbe succedere qualcosa che mi fa 
crashare il programma (o si spegne il pc... o va via la luce... o altro) 
e mi rimangono 'ste tabelle temporanee nel database.
Però se al contrario faccio una query grossa e unica (per quanto possa 
riuscirci), col tempo si tenderebbe a dimenticare il significato di 
quella query grossa com'è... poi per modificarla bisognerebbe lavorarci 
con le pinzette, perchè basterebbe un niente per non capire più dove sta 
l'errore di sintassi...
Insomma che mi consigliate?
-- 
Quando noi ignoranti eravamo di più,
tutto era più bello...
(A. Celentano)

 cancellare a fine dei lavori?
Non so Access, ma per dbms server è possibile creare tabelle temporanee con
scope limitato alla connessione, per cui n utenti possono avere n tabelle
temporanee con lo stesso nome, che spariscono alla disconnessione.
Ciao
Alberto

 Ragazzi vi chiedo un consiglio...
[...]
Recordset disconnessi... e vivi felice.
In pratica crei un recordset in memoria, lo popoli e lo usi come sorgente
di stampa.
Hai questi vantaggi:
-velocità
-impossibile mescolare per sbaglio i dati di una stampa con un'altra
(anche in caso di accesso concorrente)
-possibilità di variare le dimensioni/numero dei campi al volo, visto che
sono generati in modo procedurale.
svantaggi:
-occupazione di memoria maggiore (ma anche con 100 pagine non è
drammatico).
-non puoi usare statement SQL sui recordset disconnessi (che io sappia) ma
devi filtrare/ordinare con i metodi del recordset: es .Sort .Filter
esempio:
Set rs = New ADODB.Recordset
Call rs.Fields.Append("nome", 202, 80, 106) ' vedi la documentazione per i
significati dei numeri
Call rs.Fields.Append("cognome", 202, 80, 106)
rs.Open
rs.addnew
....
Set datareportprova.DataSource = rs
rs.close
termoPilucco
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 Insomma che mi consigliate?
Le proverei tutte e posterei i pro e i contro in una relazione pubblica
Ave
giuseppeD
---
CCR

Allora, intanto ringrazio tutti per i suggerimenti.
La strada dei recordset disconnessi mi avrebbe potuto far gola, se non 
fosse che per popolarli non posso usare query del tipo "INSERT INTO..." 
ecc. ecc.
La cosa che più mi ha colpito (diciamo che oggi mi avete dato una 
notiziona) è che le tabelle temporanee dichiarate come tali, non sono 
visibili da altre connessioni (anche sullo stesso pc), quindi posso 
creare tabelle davvero temporanee e non perdere la testa dietro nomi 
casuali...
Uso MySQL e ho appena testato sul mio stesso pc con due finestre di 
ms-dos a connettermi ai miei db: stesso db, una conessione vede la 
tabella temporanea e l'altra no.
Quindi... per fortuna che c'è MySQL :) :) :)
URRAAAAAAAAAA PER IL DOTTOR ZOIDBERG!!!
Grazie ancora a tutti!



Io in SQLServer ho usato questa tecnica:
1) una tabella di origine dei dati
2) una tabella pseudo-temporanea, nel senso che la tabella rimane ma
sono temporanei i dati;
3) la tabella di cui a 2 e' definita esattamente come la tabella di
cui a 1 con l'aggiunta di un campo numerico e di un campo data
4) il campo numerico e' destinato a contenere l'identificativo del job
di stampa; in questo modo la sovrapposizione di dati e' virtualmente
impossibile
5) il campo data serve solo all'archiviazione della data e ora di
creazione di ciascun record
6) in una tabella ho un elenco di contatori; ne dedico uno
all'attribuzione di un id di un job di stampa; dal momento che non e'
rilevante l'ordine e che ho circa 4 miliardi di jobs possibili,
semplicemente parto da -2miliardi, incremento di uno il numero di job
e lo assegno ogni volta che venga richiesto un nuovo job id
7) il job viene eliminato al termine delle operazioni
dall'applicazione; per evitare pero' problemi, istruisco l'Agente di
manutenzione in modo che controlli la tabella temporanea in modo che
tutti gli elementi tali per cui la differenza tra la data di creazione
e la data corrente sia superiore a un valore prefissato (un'ora, per
tranquillita').
Spero che ti possa servire.
--
Ciao!
Luca Menegotto

Si l'idea è buona.
E' che le tabelle temporanee sono ogni volta di tipo diverso... il mio 
programma fa una decina di stampe diverse (sicuramente anche di più, non 
le ricordo esattamente tutte), e la cosa si complicherebbe un tantino.
Comunque è una buona idea.
Però tu cancelli i dati relativi ai vair job al termine del loro 
utilizzo, vero?
E se intanto il programma crasha o non ha il tmepo di eliminarli dalla 
tua tabella pseudo-temporanea, come fai?


 tua tabella pseudo-temporanea, come fai?
"; per evitare pero' problemi, istruisco l'Agente di
manutenzione in modo che controlli la tabella temporanea in modo che
tutti gli elementi tali per cui la differenza tra la data di creazione
e la data corrente sia superiore a un valore prefissato (un'ora, per
tranquillita')."   &    "vengano cancellate automaticamente"
-- 
<Gigio2K>
--- 
http://www.g2kweb.it/gigio2k
 ---
Nokia -> I.T.H.N. -> 
http://www.ithn.it/
VB -> I.C.L.VB -> 
http://www.it-lang-vb.net/

Recordset disconnessi... e vivi felice.
Per generare una stampa di "poche" righe da un'elaborazione fatta su
"tante" righe (magari con tanti campi), è conveniente usare recordset
disconnessi? L'elaborazione viene svolta dal client e molti dati
attraversano la rete per essere elaborati.
Penso che, se si ha la possibilità, sia meglio utilizzare stored
procedure. Elaborazione dati da stampare su server (con uso di tabelle
temporanee o meno), pochi dati che attraversano la rete.
Chiaramente per aggiornare una stampa è necessario aggiornare una
procedura sul db e questo può essere un aspetto negativo.
Ciao!

 tranquillita')."   &    "vengano cancellate automaticamente"
Ops... non avevo letto tutto, ero un tantino di fretta.
Cmq vorrei evitare il più possibile di affidare qualcosa agli 
operatori... :\
"A volte il problema non sta nel software, ma fra la sedia e la scrivania"
-- 
Quando noi ignoranti eravamo di più,
tutto era più bello...
(Adriano Celentano)

 attraversano la rete per essere elaborati.
Con i recordset disconnessi devi popolare solo i dati che finiranno in
stampa.
Visto che la stampa la effettua il client, quei dati devono passare in
ogni caso dal server al client.
Usando una store procedure (o semplicemente delle query accorte) minimizzi
il numero delle richieste necessarie per ottenere i dati dal server
(quindi minimizzi la quantità di dati verso il server) ma la quantità di
dati verso il client non cambia.


Rispondo qui per non creare un altro thread (inutile): la mia versione 
del programma sta migrando egregiamente verso MySQL :)
Funziona! Dà gli stessi identici risultati della versione per MS-A-Cess, 
e riesco a dormire sogni tranquilli sapendo che esistono quelle tabelle 
fantasma che svaniscono alla disconnessione (per precauzione lancio 
sempre un DROP TABLE IF EXISTS...).
Le stampe funzionano...
Le importazioni funzionano...
La cronologia delle importazioni va una meraviglia...
Le tabelle scompaiono dopo il loro utilizzo temporaneo...
Che dire... Funge tutto!!!
Il porting è quasi completato.
Entro fine settembre mi aspettano delle pesanti modifiche per via di uno 
stravolgimento nella gestione dei pagamenti ma sapere che metterò mani 
DIRETTAMENTE e SOLO sulla versione del programma per MySQL mi alletta.
Un grazie a tutti!!!
-- 
Quando noi ignoranti eravamo di più,
tutto era più bello...
(Adriano Celentano)

dati verso il client non cambia.
Sarei d'accordo con te se non fosse che spesso sui dati si fanno
selezioni e raggruppamenti ache parecchio complessi (che sicuramente
un report normalmente non e' 'prendi un dato e mettilo in stampa').
Detto questo, comprenderai come piu' lavoro fa il server meglio e'.
Di recente ho sviluppato un report di analisi il quale sintetizzava in
una pagina un monitoraggio su un numero di records comunque superiore
a 50.000. Sei ancora convinto che sia conveniente usare i recordset
disconnessi??
--
Ciao!
Luca Menegotto

 scrivania"
bho, io spero solo che per "Agente" lui intenda un programmillo e non un
utonto !!!
Cmq sia e' facilmente gestibile :
1) hai le date dei report gia' stampati in tabelle temp
2) quando crei un nuovo report ELIMINI tutti i report antecedenti la data
attuale - 1g ad esempio
3) inserisci finalmente la tua tabella temporanea
cosi facendo anche con crash o altro sei sicuro che elimini tutto quello che
hai stampato dal giorno prima.
Unica pecca : e se la data del pc e' sfallata ? ghgh , c'e' sempre un
bugarospo che ti aspetta dietro l'angolo. ^_^
-- 
-Gigio@Work(?)-

utonto !!!
In SQLServer e' un servizio accessorio che si chiama SQLServer Agent.
Mi aspetto che anche altri DBMS abbiano uno schedulatore del genere.
--
Ciao!
Luca Menegotto

disconnessi??
Non se si usano i recordset disconnessi solo per la stampa.
Le elaborazioni vanno fatte tramite recordset normali o stored procedures.
termoPilucco

procedura sul db e questo può essere un aspetto negativo.
Boh, forse ho letto male il post originale (anzi di sicuro), ma quando ho
suggerito di usare recordset disconnessi mi riferivo ai dati che finiranno sulle
stampe, che non possono essere di più di quelli che si vedono.
Il modo per ottenere i dati da inserire nei recordset disconnessi è ovviamente
quello tradizionale (query/stored procedures/quant'altro).
termoPilucco

quello tradizionale (query/stored procedures/quant'altro).
Se è così sono daccordo con te, ovvero i recordset disconnessi possono
essere una buona soluzione.
Ciao!