Newsgroup: it.comp.lang.visual-basic
Titolo: Su velocità Database Access in rete

Salve a tutti,
se in un database, utilizzato da client, che serve soprattutto da 
contenitore (il DB col tempo quindi diventa sempre più voluminoso), ci 
sono due, tre tabelle che, in realtà, vengono utilizzate di più e 
servono da contenitori temporanei e per modificare vari valori, mi 
domandavo, se queste tabelle fossero spostate in un altro file database 
esterno, i collegamenti Client/server sarebbero più veloci dato che la 
grandezza di questo secondo database sarebbe sempre molto piccola?
Ovvio che ogni tanto i valori vengono definitivamente anchiviati nel DB 
centrale, ma questo è un lavoro che fa principalmente il server e quindi 
non inciderebbe sui client.
Grazie in anticipo
Robin

 ha scritto nel messaggio
news:46ddd081$0$16037$5fc...@news.tiscali.it...

Access in rete non è il DB adatto.
Access è un'ottimo DB da uso locale, per salvare i LocalSettings...
Se lato Server avessi un DB_SERVER non avresti questi problemi in nessun
caso...!
-- 
@Alex (Alessandro Baraldi)
---------------------------------------------------------------------------
http://www.sitocomune.com/
http://www.alessandrobaraldi.it
---------------------------------------------------------------------------

 caso...!
E bè, lo so; ma purtroppo l'aaplicazione in VB6 è fatta con access. 
Magari dovrei vedere se trasformo il db di access con le stesse tabelle 
e gli stessi nomi in un DB SQLServer. Non è che magari esiste qualche 
utility in proposito che mi può far questo no?
Grazie comunque.
Robin

robin ha scritto:

SQL Server 2000/2005 stesso ha un tool di conversione.

 Robin
Ciao,
in Sql Server trovi l'utility "Importazione/Esportazione guidata DTS" 
che ti consente proprio di fare quello che ti serve.
In SQL Server 2005 Express non ricordo se la voce sia la medesima, ma 
comunque non dovresti incontrare problemi.
Una volta importati i dati, l'unica cosa che devi fare è modificare solo 
la stringa di connessione (se usi ADO), dopodichè tutto dovrebbe 
funzionare, salvo qualche piccolo aggiustamento tra cui quello dovuto 
all'eventuale utilizzo di date non in formato ISO.
Naturalmente lasciando tutto così sfrutteresti solo una frazione delle 
potenzialità offerte da SQL Server, i miglioramenti più grossi li 
avresti spostando tutta la logica lato server.
ciao
stefano

 stefano
Ciao Stefano,
SQL server, come avrai, penso, capito, non lo conosco accidenti. Ma 
forse comincio a pensare che val la pena di impararlo. MA adesso 
gentilmente mi potresti postare la stringa di connessione unzippata per 
SQLServer? E un'altra domanda, tutti i report creati con Crystal report 
(lasciano intatto tutte le tabelle i nommi ecc. ma traaformato il 
SQLServer)  mi funzioneranno dopo?
Scusa se approfitto, ma almeno per inziare forse potrebbe valere la pena 
già traformare il DB Access in SQLServer. Ma poi, spostare tutto sul 
lato server cosa intendi dire precisamente?
Grazie in anticipo.
Ciao
Robin alias bygv (ma tanto mi conosci già). :-)

 Robin alias bygv (ma tanto mi conosci già). :-)
:-)

> Robin alias bygv (ma tanto mi conosci già). :-)
Intanto grazie della pazienza.
Le Sp, i trigger, le viste, le UDF, bè qualcosa ho fatto con Interbase 
(alias Firebird) ho provato a creare un database con Firebird uguale a 
quello access, ma posso collegarmici solo via ODBC. Non mi convine fare 
tanto lavoro per poi dover modificare tutte le chiamate al DB. E poi 
Crystal Report con Firebird non funziona di sicuro.
Va bè vedremo, intanto con quei tuoi suggerimenti "unzippati" ho 
risolto, devo convenire, in modo molto bello, tuii i problemi. Il DB 
funziona bene, i dati che deve incamerare nn sono tantissimi, e forse 
access può anche bastare per fare tutto il lavoro che deve fare. :-)
Cmq, credo che comprerò qualche testo per imparare SQLServer. Io in 
realtà avevo optati per Firebird in quanto è Free e con Delphi va a 
gogò. Ma purtroppo continuo ad avere un certo debole per visual basic. :-)
A risentirci.
Ciao
Robin

 Robin
Ciao e buon lavoro.
stefano

 Crystal Report con Firebird non funziona di sicuro.
Crystal Report con Firebird funziona di sicuro
Io sono convinto che se devi fare un lavoro e' meglio che lo fai bene dalla 
prima volta, alias, continua ad usare Firebird, non c'e' proprio paragone 
rispetto ai file db formato Access
Ciao
RobertoA

> E poi Crystal Report con Firebird non funziona di sicuro.
Ciao. Non conosco Firebird, ma se ti connnetti a Firebird via ODBC puoi
tranquillamente utilizzare anche Crystal Report. Il trucco è appoggiare i
report di CR ad un DSN, invece che direttamente al database.
I DSN utente e i DSN di sistema si creano e si gestiscono
dall'amministrazione ODBC - es. in XP, Strumenti di amministrazione/Origine
dati (ODBC) - nel Pannello di controllo di Windows.
In seguito, quando cambierai il motore database utilizzato, potrai
modificare l'impostazione del DSN stesso e Crystal Report continuerà a
funzionare ugualmente. L'unica accortezza è che dovrai pensare a come
modificare o ricreare il DSN su ogni client, a meno che i client non siano
talmente pochi che è meglio farlo a mano su ognuno: infatti, mi sembra di
capire che tu abbia l'esigenza di gestire al massimo cinque o sei client e
in tal caso entrare nel Pannello di controllo di ognuno e cambiare le
impostazioni del DSN è una bazzecola, e va fatto una volta sola.
Altrimenti, se devi aggiornare molti client, esistono anche delle funzioni
per creare e modificare i DSN via codice VB. Significa che potresti perfino
creare e distribuire un piccolo eseguibile usa-e-getta apposito per
modificare il DSN sui client. Io spesso distribuisco dei piccoli eseguibili,
insieme ai nuovi report o alle nuove versioni, se devo mettere mano al
Pannello di controllo di Windows.
Naturalmente il discorso su Crystal Report e DSN vale anche lavorando con
Access, con SQLServer o con MSDE.
Sempre se non intendi rifare tutto in Delphi.
Spero sia utile. Ciao.
--------------------------------
Inviato via 
http://arianna.libero.it/usenet/

 Crystal Report con Firebird funziona di sicuro
Questa è una bella notizia, non avevo mai provato.
Ma via ODBC mi pare che il collegamento wireless sia un pò lento. Mi 
puoi smentire? :-) Se si, ne sarò lieto.
Ciao e grazie
Robin


 Robin
E perche' ti pare che sia lento ?
Lento rispetto a cosa ?
Io lo uso spesso e mi sembra possa andare piu' che bene
Certo che se ti attacchi a tabelle da milllllioni di righe e lo fai filtrare 
su colonne non indicizzate allora bisogna avere un attimino di pazienza
Personalmente l'archivio piu' grosso di Firebird sul quale ho usato CR e' un 
db da 2 Gbyte, tabella testate documenti da 400-450K righe
Tabella righe documenti da 3M righe circa
Stampare una fattura e' quasi istantaneo (dando come filtro un campo 
indicizzato ed ovviamente avendo come collegamento testate-righe dei campi 
indicizzati)
A mio parere, CR e' un ottimo sistema
Ciao
RobertoA

 Lento rispetto a cosa ?
Mi spiego meglio.
Ho la necessità di collegarmi con un wireless ad un server, è i 
collegamenti dovrebbero essere molto frequenti. Io, considera che nn ho 
esperienza, pensavo che con un collegamento ODBC su firebird il 
collegamento potrebbe essere più lento rispetto al collegamento con ADO. 
Ma se mi puoi smentire mi farebbe piacere perchè vorrebbe dire che 
potrei lavorare con firebird il che mi piacerebbe in quanto già lo 
conosco discretamente.
Grazie comunque
Robin

yronium ha scritto:

Ok, Grazie,
Ma gentilmente, mi potresti fare un esempio di codice (due righe) di 
come dico a CR che invece del database "c:\programmi...\miodb.mdb"
deve usare questo DSN? :-)
Scusa la mia ignoranza... ma così mi veiene difficile riutilizzare i DSN.
Grazie comunque


Non ho mai fatto test precisi su prestazioni usando lo stesso db via odbc e 
via ado
Immagino che via ado sia piu' veloce, pero' non so di quanto ed in che 
condizioni
Quello che ho riscontrato con Firebird e' che, anche avendo db di dimensioni 
discrete (diciamo dai 500 Mb in su), le procedure rimangono perfettamente 
utilizzabili anche se vanno ad interrogare tabelle da milioni di righe
Personalmente mi prefiggo un ritardo massimo di 6-7 secondi dall'avvio 
interrogazione alla visualizzazione del risultato, ma questo deve rimanere 
un caso limite
Oltre quel tempo, l'operatore inizia a pestare sul mouse e sulla tastiera a 
meno che non gli spari fuori un bel massaggio con scritto
"PAR CARITA' NO STA TOCCARE GNENTE - ELABORASSION IN GORSO"
Ovviamente un occhio agli indici ed un altro al numero di colonne/righe da 
leggere bisogna mettercelo
Se ti metti in testa di leggere un milione di righe per metterle in griglia, 
allora il sistema potrebbe anche essere lievemente 'appesantito' e perdere 
di reattivita'.
Ciao
RobertoA

 deve usare questo DSN? :-)
Eccomi. Scusa il ritardo ma sono stato fuori città per un paio di giorni.
Dunque ti incollo un pezzo di codice funzionante per aprire il report.
    ' questa variabile contiene la vista (query) che serve da base dati per il
report
    ' questa vista è già salvata dentro il database, ma niente ti vieta di
creartene una on-the-fly,
    ' salvarla dentro il database con un nome fittizio, eseguirla con questa
chiamata, e distruggerla
    ' quando hai visualizzato il report. Tutte queste operazioni le puoi fare
per mezzo di
    ' istruzioni SQL, da costruirti come normali stringhe di testo e da eseguire
con cn.Execute
    nomevista = "vReportDistinta"
    ' imposta il path per il report
    reppath = App.Path & "\DistintaElettronica.rpt"
    With CR1
        .ReportFileName = reppath
        ' costruisce la stringa per la proprietà Connect
        rcon = "DSN = " & "DbFatture"
        rcon = rcon & ";UID=" & "yronium"
        rcon = rcon & ";PWD=" & "mia_password"
        .Connect = rcon
        ' imposta l'aspetto e i parametri di visualizzazione del report
        .Destination = crptToWindow
        .WindowHeight = 600
        .WindowWidth = 800
        ' visualizza il report in una finestra massimizzata
        reportoption = 2 ' 2 = pieno schermo
        .WindowState = reportoption
        .WindowShowCloseBtn = True
        .WindowShowPrintSetupBtn = True
        .WindowShowZoomCtl = True
        ' imposta la vista selezionata come origine dati per il report corrente
        ' (l'indice zero è obbligatorio)
        .DataFiles(0) = "dbo." & nomevista
 
        ' passa la formula di filtro al report:
        ' la vista restituisce tutti i record a Crystal Report, ma applicando un
filtro si può mostrare
        ' soltanto il record il cui ID è uguale al valore della variabile
IdDistintaRichiesta;
        ' un metodo più efficiente consiste nel filtrare il report direttamente con
un criterio WHERE
        ' nella vista, specialmente quando la vista viene creata on-the-fly, ma in
questo modo puoi
        ' vedere un esempio pratico di come si applica un filtro ai valori
restituiti dalla query.
        ' Questo procedimento è equivalente ad aver impostato una formula di filtro
dentro il report
        ' stesso, tramite il menu Report/Edit Selection formula/Record di CR
        formulatext = "{qry.IDDistinta} = NNN"
        formulatext = Replace(formulatext, "NNN", IdDistintaRichiesta)
        .SelectionFormula = formulatext
        ' infine, quando tutti i parametri sono impostati, apre realmente il report
        ' se ricevi un errore dopo questa istruzione significa che qualche parametro
non è impostato
        ' correttamente, es. il campo IDDistinta non si chiama così, o il nome del
DSN è sbagliato, ...
        .Action = 1
        ' dopo aver aperto il report, imposta il fattore di zoom
        reportoption = 80 ' 80, significa 80%
        .PageZoom reportoption
    End With
Spero ti sia utile. Ciao.
