Newsgroup: it.comp.appl.access
Titolo: Ma SQL Server 'server' solo a Microsoft ?

Sto facendo delle prove per confrontare Access con SQL Server.
Parto dal presupposto che lavoro su database di massimo 500 Mb ma
anche con una trentina di utenti.
In seguito alle prove DAO/ADO ho deciso di continuare ancora con DAO
in quanto trovo ADO limitato e lento per database con le
caratteristiche indicate sopra.
Alcuni mi fanno notare che occorre lavorare con stored query ma se uno
fa una query di selezione non puo' fare una stored query (o no ?)
Tempi misurati per una query su 4 tabelle correttamente indicizzate in
cascata con 5000 record risultanti, tempo di apertura e posizionamento
sull'ultimo record.
25 secondi con SQLServer (13 se di snapshot)
2 secondi su MDB locale (1 se di snapshot)
4 secondi su MDB di rete accedendo in 4 (2 se di snapshot)
:-(
----------------------------------------------------------
Paolo Hölzl
Gruppo Tekup Software developer (Bologna)
----------------------------------------------------------
ATTENTION!, antispam 
For reply, substitute xxx with gruppotekup

 4 secondi su MDB di rete accedendo in 4 (2 se di snapshot)
Molto probabilmente hai toppato tu qualcosa.
Posso capire un certa differenza fra DB locale e in rete, ma fra due DB in
rete, SQL č molto piů performante, secondo me.

SQL è molto più performante, secondo me
Su pochi dati e pochi utenti ho bisogno di qualcuno che me ne dia la
certezza, e che la dimostri e non vada per sentito dire, vendere un
programma con allegato il costo e la complessita' di SQL server per un
applicativo non particolarmente pesante, richiede dei validi motivi di
fondo.


 fondo.
Io non parlo per sentito dire, ma per esperienza diretta.
Access, in multiutenza (se così si può definire), è molto limitato e si
pianta presto.
Access, appoggiato ad un back-end su SQL, è ancora instabile, ma molto meno,
te l'assicuro.

In con multiutenze fino a 10 posti di lavoro (anche con archivi abbastanza pesanti) non ho avuto
grossi problemi con ms jet.
Dipende anche dalla qualità dell'hardware di rete.
Oltre non ho esperienza diretta, ma da quanto scrivi (e non mi sembra che tu stia barando) sembri
abbastanza soddisfatto.
Vuoi parlarne?
Ciao, Mauro

pianta presto
Quanti posti di lavoro?
Che cavi e schede di rete?
Quando leggo queste cose tendo sempre o a spaventarmi o a considerarmi estremamente fortunato.
Come ricavi dal post sopra non ho avuto modo di spingermi oltre certi numeri, ma fino a 10 client
(certo non con le Realtek) per mia esperienza Access puň tenere benissimo.
Dipendentemente anche dalla pesantezza dell'applicazione e degli indici.
Ciao, Mauro

 Dipendentemente anche dalla pesantezza dell'applicazione e degli indici.
Eh?

pianta presto.
Ma scherziamo ???
Ma ti pare che uno possa lavorare su database che si 'piantano' ?
Ho programmi fatti in Access2, Access95, Access97 i piu' vecchi
lavorano da almeno 5 anni con mediamente 4 utenti collegati e ti
garantisco che non ce n'e uno che si pianti.
Neppure quello piu' recente che ha 25 utenti collegati.
Tra l'altro alcuni lavorano con dati 'sensibili' e a contatto con il
pubblico (gente davanti allo sportello).
I piantamenti quando ci sono sono dovuti principalmente a questi
fattori:
Gestione del lock errata da parte del programmatore (raro in quanto a
parte casi particolari il default lavora bene).
Su Access2 (ma solo sul 2) la gestione del lock faceva si che in caso
di una macchina in rete molto lenta non rilasciava quasi mai il lock
(ma era correggibile via software).
Il problema piu' grave e' tuttavia quello legato a una rete
malfunzionante (spesso colpa delle schede di rete Realtek e affini).
Alcune schede di rete di questo tipo in particolar modo in presenza di
macchine veloci perdono qualche dato 'ogni tanto'.
E' un errore spesso difficile da diagnosticare in quanto la rete
apparentemente funziona, l'errore si genera solo sotto carico, spesso
basta fare un XCOPY /S sulla rete perche' si sganci la connessione
alla rete palesando il problema.
In presenza di tale problema alcuni utenti neppure si accorgono di
averlo ma se gira un Database Jet condiviso si corrompe molto
facilmente, ogni tanto.
Abbiamo avuto nel tempo 3 casi e li abbiamo risolti tutti trovando la
scheda di rete maledetta e sostituendola.
I nostri programmi sotto Access sono stabilissimi e non perdono un
dato (ci mancherebbe solo questo).
Evidentemente SQL Server e altri Database Server hanno protezioni piu'
sofisticate ma e' un altro concetto.


Eh?
DIPENDENTEMENTE DALLA PESANTEZZA DELL'APPLICAZIONE E DAGLI INDICI MULTICAMPO CHE TANTI FURBACCHIONI
SBATTONO DAPPERTUTTO.
così è chiaro o vuoi solo far casino?
Mauro

 dato (ci mancherebbe solo questo).
Mai detto che perdono dati. Dico solo che Access per natura è instabile. Lo
è ancora di più quando cilavori in multiutenza.
Se a te non capita, buon per te.

Ciao,
dimmi pure che access in multiutenza perde prestazioni e che con un alto nr
di record puo' andare in crisi (indicizzazioni errate a parte), ma non dire
che e' instabile.
Non che voglia difendere Access a spada tratta ma NON PUOI dire una
sciocchezza simile, puo' darsi che sia "instabile" il codice del tuo Dbase e
che non preveda certe tipologie di errore.
Anzi' andro' oltre, dato che ho avuto l'occasione di provare SQL Server
2000, ti diro' che il suo motore e' mooolto instabile e si perde in errori
ODBC su query relativamente semplici (speriamo sia solo un difettuccio della
Beta Release).
In ogni caso se non hai bisogno di prestazioni astronomiche (cioe'
statistiche e ricerche continue al posto del data-Entry classico) e stai
sotto i 15 utenti Access e' la scelta migliore sia per facilita' d'uso che
per costi.
<LuigI>
Andrea Sciamanna <andrea.s...@libero.it.cancellami> wrote in message
8me65b$fuj$1...@serv1.iunet.it...



Guarda, ti consiglio di leggere meglio quanto ti scrive Paolo Holzl in merito a ms jet invece che
diffondere allarmismi in buona misura eccessivi su un'area pubblica che vive su Access.
Non basta una buona scheda di rete (3com o Intel che sia) a rendere affidabile una Lan.
Trovati un collaboratore di fiducia che certifichi ISO reti a 100 mb/s.
Tieni presente che esistono molti fattori che possono far decadere le prestazioni di un file-server
in rete: server non dedicato o vetusto, altri software client-server in rete (MS-FAx o le rare
famigerate installazioni client-server di Office), colli di bottiglia dovuti a cavi o hub comprati
"d'occasione", programmi scritti in modo troppo artigianale.
Questo è il vero *grosso* difetto di Access: gli eccessi di flessibilità che a molti fanno male.
Mauro

 così è chiaro o vuoi solo far casino?
Non c'era assolutamente bisogno di urlare: questo dimostra il fatto che,
forse, sei tu a voler fare casino.
Del resto, era sufficiente scrivere la stessa frase, senza urlare, per
spiegare meglio una condizione che mi sembrava scontata e che, per sicurezza
ho voluto chie tu chiarissi. Il tuo chiarimento, anche se riportato in
maniera molto maleducata, ha confermato la scontatezza della tua
affermazione.

 che non preveda certe tipologie di errore.
Può darsi. Non mi ritengo un professionista nel campo, ma, sicuramente, mi
ritengo sono più competente di tanti che si ritengono tali.
Questo per dire che ho un minimo di sicurezza sul codice che scrivo.
Del resto, mi capita, tanto per fare un esempio, un caso che non voglio
nemmeno provare a risolvere, per ora.
Dal cliente ho installato su una decina di macchine il FE di un'applicazione
in ACC2000, su base dati SQL.
Su alcune macchine non ci sono problemi, su altre, appena aperto
l'applicativo pippo.mdb, Access se ne esce fuori dicendo che non trova
pippo.mdb. Dando ok l'applicativo continua a girare senza problemi.
Molto stabile Access.
Altro caso (ho lo screen shot inviato dal cliente, giusto sotto il naso):
Il cliente lavora su una maschera.
Viene fuori il msg "errore riservato (-7776); non ci sono messaggi per
questo errore.", dopodichè il programma continua a funzionare senza
problemi.
Questi, per me, sono segni di instabilità. Poi, se vuoi, si può
filosofeggiare sul significato di instabilità, ma, per ora, io resto di
questa opinione.
Sono solo contento di non avere ancora perso dei dati, ma tremo all'idea.
E nono posso dare la colpa a SQL, visto che, come minimo, dovrei vedere un
msg del tipo "Errore ODBC: ...."

 Questo è il vero *grosso* difetto di Access: gli eccessi di flessibilità
che a molti fanno male.
Di grazia, quali sarebbero questi "eccessi di flessibilità"?

Ciao,
voglio chiudere qui la discussione tanto non e' che posso inculcarti le mie
idee in testa usando la forza, comunque permettimi di dire che dopo lo
sviluppo di applicazione Access (sia multiutenza che utente singolo), Visual
Basic e Power Builder (ottimo prodotto peccato che abbia un linguaggio di
programmazione molto piu' simile ad uno script) qunado ho trovato un errore
e' sempre stato perche' avevo scritto male il codice o perche' c'era un'
applicazione esterna che interferiva con il mio programma.
Ti cito l'ultimo caso capitatomi con un programmino di Help Desk scritto in
Access 2000 per 5 utenti:
4 funzionavano perfettamente ed 1 invece non riusciva ad aprire MsWord per
la composizione di lettere ad Hoc, il problema era che Norton Antivirus 2000
(installato solo su quel PC) interferiva e non lasciava creare l'oggetto
Word (Bug documentato sia sul sito Norton che su Quello Ms).
Per questo motivo ti consiglio (se gia' non lo fai) di testare il tuo
applicativo su un PC con il solo SO piu' gli eventuali driver ed
aggiornamenti minini indispensabili in modo da esser sicuro che sia esente
da BUG e di controllare che gli errori verificatisi dal clienti non
dipendano dalla particolare configurazione della macchina dello stesso o da
percorsi lasciati scoperti (ho visto personalmente gente che riusciva a
scivere in determinate situazioni su campi bloccati); a quel punto allora
potrai parlare di instabilita' (o BUG) del tool di sviluppo e sta pur
tranquillo che nessuno ti dara' mai contro.
Inoltre ti ricordo che nella programmazione odierna (specialmente ad eventi)
il singolo errore puo' essere scatenato da n fattori concomitanti e casuali
tanto che a volte nemmeno un debug approfondito con tanto di Log aiuta a
chiarire le cose.
<LuigI>

 chiarire le cose.
Hai ragione. Ripeto, però, che determinati errori sono, in maniera evidente,
indipendenti dal codice, come i due casi che ti ho presentato.


Per te non è scontata visto che i tuoi lavori sono "instabili" perfino in monoutenza.


Scoprili da te visto che sai già tutto *grazia*


Beh, vedo che una competenza ce l'hai: quella di mettere le parole in bocca
agli altri.
Io dico che Access è instabile e tu concludi che sono i miei lavori ad
esserlo. Vabbè, fai tutto tu. A questo punto, purché non continui il thread
da solo? Ti scrivi e ti rispondi. Nella realtà si chiamerebbe soliloquio, in
un NG non saprei.

 Scoprili da te visto che sai già tutto *grazia*
Congratulazioni! Questo è il modo per rispondere ad una domanda.
Buon lavoro (per quel che ti può servire un mio augurio).

un NG non saprei.
Rileggi i tuoi post bimbo, rileggi....


Gli auguri, vista l'affidabilità dei tuoi lavori, servono più a te!!
Addio

 Addio.
Magari fosse così, ma mi toccherà leggerti, tanto per il gusto di
contraddirti alla prima occasione (cosa che ho già cominciato a fare).

contraddirti alla prima occasione (cosa che ho già cominciato a fare).
Attento, potrei prenderci gusto...