Newsgroup: it.comp.lang.visual-basic
Titolo: SQL Server? mi aspettavo...ma sono perplesso....

Ciao a tutti
mi sto accingendo a conoscere SQL Server 2000! al momento dell'installazione
mi ha detto che poteva solo installare i componenti client (forse xche ho
w98?) e fin qui suppongo che sia tutto OK...
Da quanto ho capito, a prima vista, mi sembra che questo SQL Server 2000 non
sia un vero editor di DB, tipo come Access (dove puoi crearti tutto) ma
sembra più un utilità che serve a far risiedere un DB (Access,Excel,txt...)
su un Server (suppongo con un SO WinNT,XP,2000) chiaramente in rete, dove i
vari client possono attingere informazioni....
Ho capito bene?
Vorrei fare un test, con ADO magari creandomi un DB via codice VB e SQL
ma per provarlo ho, per forza di cose, bisogno di installare i componenti
Server???
e per questo devo avere un'altro PC con una mia piccola rete e con magari un
SO WinNT?
Rimango perplesso... mi aspettavo una cosa del tipo Access che puoi fare
tutto via pacchetto... e che poi puoi fare anche via codice VB ma sembra che
quello che cambia sia solo il metodo di connessione DNS... in un DB SQL
Server 2000 (ma esiste?!!!)
:(((
Qualcuno che lo usa potrebbe illuinarmi un'attimino sull'ABC?? 8P
Grazie
Fabio

 ha scritto nel messaggio
news:vgVC8.17491$g04....@tornado.fastwebnet.it...

Per i sistemi vai a questo indirizzo
http://microsoft.com/sql/evaluation/sysreqs/2000/default.asp
 dove ho appena
scoperto che sul mio nuovo XP Pro non posso installare il disponibile SQL
Server 7.0 (grazie mamma M$!).
Comunque sia, hai capito bene: SQL Server è, appunto, un server. Non ti
serve necessariamente un PC separato, puoi montarlo su di un PC che abbia un
SO adeguato e poi lo chiami con ADO.
Proprio oggi ho fatto delle prove di velocià (mi stava sul gozzo da tempo),
sia sul server che da una (OK, una sola) postazione client, su archivi
identici. Questa la classifica:
1° DAO+Access
2° ADO+Access
3° DAO+SQL Server con tabelle collegate e ODBC
4° ADO+SQL Server
Un'idea per chiudere e aprire un recordset di 41.000 records x 7 campi, per
50 volte?
Con Server P3 1Ghz, NT4 SP5, SQL7 SP2, DAO 3.6, ADO 2.50:
DAO+Access=0.167 secondi
ADO+Access=0.582 secondi
DAO+SQL Server (tab.collegate)=1.984 secondi
ADO+SQL Server cursore lato server=22.128 secondi
ADO+SQL Server cursore lato client=60.780 secondi
Sic!


Aspetta aspetta!
stai dicendo che access è più veloce di sqlserver?
dai, non ci posso credere!
allora perchè sqlserver costa 50 milioni?
Scusa è una ladrata, l'unica vera differenza sta nella dimensione del
database, quanto può essere grande, a questo punto.
Ciao

 stai dicendo che access è più veloce di sqlserver?
Per ora mi limito ad affermare che è ADO più lento di DAO.
SQL Server più lento di Access? L'hai detto tu... ;-)))
Per il resto, in tutta franchezza, vorrei saperlo anch'io: Spendo 500
milioni per una bellissima Ferrari (o Porsche o quello che vuoi tu), ma mi
viene flangiata per andare a 130 all'ora. Stabilità, sicurezza, concorrenza?
Sarà...

 ADO+SQL Server cursore lato client=60.780 secondi
Potresti descrivere meglio il test? Perché sono convinto che
ci sia un errore basilare alla base, perché tempi simili non
hanno il minimo senso.
P.S.
A scanso di equivoci, non sto mettendo in minimo dubbio la tua
buona fede nello svolgimento del test.
Ciao.
--
BSD is for UNIX-lovers -- linux is for Windows-haters.

 buona fede nello svolgimento del test.
Sono stato il primo a voler fare qualcosa di assolutamente pulito e semplice
e sarei il primo ad essere felice di scoprire un errore.
Il metodo del test è semplice: Ho un MDB che contiene una tabella con tutti
gli sportelli bancari italiani. Ho un MDF che contgiene esattamente le
stesse informazioni. Il test si limita ad aprire il db o la connessione,
"congela" il valore di Timer e ripete per 50 volte la chiusura del recordset
e la sua apertura con una normalissima Select * From Sportelli (per ADO:
cursore lato server, blocco ottimistico, Static). Alla fine ricava
Timer-timer_congelato ed espone il tempo impiegato.
Posso spedire a chi può far due prove anche il sorgente, o a pubblicarlo
qui.
Intanto cito la Sub che si occupa dell'apertura:
--------------------
Sub apri_rs(db, rs)
'       Apre su "rs" il recordset per "n" volte
    Screen.MousePointer = vbHourglass
    If Val(volte) = 0 Then volte = "1"
    For n = 1 To Val(volte)
'           Prima chiude
        On Error Resume Next
        rs.Close
        Set rs = Nothing
        On Error GoTo 0
        If opt_ado Then
'               ADO
            Set rs = New ADODB.Recordset    'Crea l'oggetto
            rs.CursorLocation = IIf(opt_server, adUseServer, adUseClient)
'Lato cursore
            tipo_apertura = adOpenStatic    'Modalita' apertura
'               In presenza di "DISTINCT" e' necessario assegnare
'               il tipo di lock a ReadOnly per ottenere un cursore
'               scorrevole (con bookmarks)
            If InStr(UCase(txt_sql.Text), " DISTINCT ") Then
                tipo_apertura = adLockReadOnly
            End If
            rs.Open txt_sql.Text, db, tipo_apertura, adLockOptimistic
'Apertura
        Else
'               DAO
            Set rs = db.OpenRecordset(txt_sql.Text, dbOpenDynaset,
IIf(chk_sql_server, dbSeeChanges, 0))   'Apertura
        End If
        If chk_movelast Then
'               Previsto il MoveFirst e il MoveLast da apposito checkbox
'               Da prove fatte, e' praticamente ininfluente, anche in ADO
            rs.MoveFirst
            rs.MoveLast
        End If
    Next n
    Screen.MousePointer = vbNormal
End Sub
--------------------
HPL: Queste prove sono state fatte su 3 sistemi diversi e, a parte le
diverse caratteristiche hardware, sono stati confermati. Anch'io credo che
non sia possibile, ma così è. Puoi darmi una mano se ti mando il progetto?
Grazie.

 > DAO+SQL Server (tab.collegate)=1.984 secondi
collegate come e dove ?
scusa, ma non conosco sqls, e anche in access non ne ho mai usate.
hai usato il motore di sqls collegandogli le stesse tabelle dell'access del
test ?
ciao, a.


 Server 7.0 (grazie mamma M$!).
scusa, dove hai letto che Sql7 non e' installabile su WinXP PRO??
grazie
Andrea Montanari
montanar...@virgilio.it
http://utenti.lycos.it/asql/index.html
(my vb6+sql-dmo little try to provide MS MSDE 1.0 a visual interface) ver
0.0.35
--------- remove NOSPAM to reply

 ciao, a.
Per quanto riguarda ADO verso SQL Server ho creato archivi Access
normalissimi che ... non contengono niente, se non le tabelle vuote. La
proprietą Connect di ogni tabella contiene, di fatto, la stringa di
connessione (ODBC, senza DSN e con autenticazione WinNT) verso la omologa
tabella di SQL Server. Quindi DAO chiama Jet/Access, questo attiva ODBC che
consente di arrivare a SQL Server.
Ecco la Connect della tabella SPORTELLI:
ODBC;DRIVER={SQL
SERVER};SERVER=NOME_SERVER_SQL;UID=;TRUSTED_CONNECTION=YES;DATABASE=ESD00COM
;DSN=;

 grazie
In effetti mi sono spiegato male: Ho letto quell'articolo dopo aver provato
a installare su Win XP Pro SQL Server dagli stessi CD di SQL Server 7.0
(MSDN Universal, quelli, per intenderci, che partono con le opzioni
Prerequisites, Components e, da questi, Standard Edition). La risposta è
stata: "The Standard Edition server component canno be installed on Windows
NT WorkStation using this CD. Only client components will be available for
installation.". Ripeto: Con gli stessi CD (April, 1999) ho sempre installato
su NT Server 4 Sp5. Dispongo anche di SP1 e 2 di SQL Server 7.
Da qui ho ... dedotto che ... quei CD non riconoscono XP (nato dopo) come
sistema adatto a installare il componente Server.
Puoi dirmi, gentilmente, come faccio a installare su XP?

 ha scritto nel messaggio
news:53XC8.41242$5k4.8...@twister2.libero.it...


 ha scritto nel
messaggio news:EcXC8.29249$CN3.8...@news2.tin.it...


 trovato
Andrea, abbi pazienza, ma non ci ho capito molto: Se installo su XP Pro,
devo installare la versione DeskTop?

 ha scritto nel messaggio
news:9sXC8.41358$5k4.8...@twister2.libero.it...

Comunque, nel link che avevo citato prima, pur parlando di SQL 2000 (non ho
trovato qualcosa di simile per SQL 7.0), si dice quanto riporto sotto. Nota
particolarmente che per la Standard Edition non si cita XP, ma solo per la
Trial e Personal. Se lo stesso vale per SQL 7.0...
SQL Server 2000 Enterprise Edition and Standard Edition run on Microsoft
Windows® 2000 Server, Windows 2000 Advanced Server, Windows 2000 Datacenter
Server operating systems, Microsoft Windows NT® Server version 4.0 Service
Pack 5 (SP5) or later, and Windows NT Server 4.0 Enterprise Edition with SP5
or later
• SQL Server 2000 trial software and SQL Server 2000 Developer Edition run
on the operating systems listed above for the Enterprise and Standard
Editions as well as on Windows XP Professional, Windows XP Home Edition,
Windows 2000 Professional and Windows NT Workstation 4.0 with SP5 or later.
• SQL Server 2000 Personal Edition¹ and SQL Server 2000 Desktop Engine run
on the operating systems listed above for Enterprise and Standard Editions,
as well as on Windows 98, Windows Millennium Edition (Windows Me), Windows
XP Professional, Windows XP Home Edition, Windows 2000 Professional, and
Windows NT Workstation 4.0 with SP5 or later.

 scoperto che sul mio nuovo XP Pro non posso installare il disponibile SQL
Io l'ho installato senza problema, basta avviare il programma di
installazione con i parametri k=dk per installare la desktop edition e tutto
fila che è una meraviglia (sempre che tu parli di mssql7, ma per il 2000
dovrebbero esserci ancora meno problemi)

 Puoi darmi una mano se ti mando il progetto? Grazie.
Volentieri, perché, ripeto, mi pare una cosa impossibile. Che
DAO + Acces sia più veloce di ADO + SQL Server posso capirlo,
in fondo si tratta di un semplice accesso ad un file contro
una (complessa) architettura client-server, ma differenze così
enormi mi paiono assurde.
Puoi mandarmi il progetto (ed il db) su:
mio_indirizzo_ip(dagli header)/upload.html o via mail
all'indirizzo hDOTpDOTlDOTmailATsoftsharkDOTorg.


 il componente Server.
No, no, è normale. Su NT Wks, Win2000 Pro, XP Pro, puoi solo
installare la versione desktop. Il componente server lo puoi
installare solo su NT e 2000 server (ed XP quando uscirà la
versione server).


 versione server).
Vabbè, ma la versione desktop mi consente di gestire un db SQL Server sulla
stessa macchina? Sennò come faccio a usare SQL Server sul mio portatile
scollegato dal resto del mondo? Scusa, sto sicuramente facendo confusione,
ma non ho ancora capito e cerco di spiegarmi meglio:
Ho un portatile con XP Pro. Come posso montare SQL Server 7.0 (e poi SP1 e
2) sullo stesso portatile con l'intento di gestire database anch'essi da
installarsi sullo stesso portatile?
Grazie della pazienza.

 all'indirizzo hDOTpDOTlDOTmailATsoftsharkDOTorg.
Ho mandato una mail (anzi due, ma sulla prima avevo dimenticato l'allegato)
all'indirizzo sopra (sostituendo DOT e AT con . e @) con il file
ESDAOADO.ZIP che contiene l'intero progetto.
Grazie della tua disponibilità e pazienza.

 SQL Server sulla stessa macchina?
Certamente, ha alcune (molte) funzionalità in meno (molte
delle quali dipendenti da mancate caratteristiche del SO), ma
come database è utilizzabile alla perfezione.


viene flangiata per andare a 130 all'ora. Stabilità, sicurezza, concorrenza?
Appunto prova tu con access a far accedere a 30+ client al db... poi
vedi un po' tu cosa ne resta! :P
-- 
Visita il sito comune del NG: 
http://www.it-lang-vb.net
Visit: 
http://www.hardwaretips.com


prima di tutto vorrei dare un'occhiatina al codice del test (in particolare
al SQL utilizzato) e in seguito ai database utilizzati (tabelle, indici,
ecc. ecc.) ;
secondo, rifai la stessa prova con 3 o 4 client collegati allo stesso db,
poi magari ne riparliamo....
ciao

Rispondo a tutti con i risultati che H.P.L. mi ha comunicato dalle sue
prove:
DAO + Access            0,062
ADO + Access            0,171
ADO + SQL Server     0,343
E ora, considerando questi dati molto piů coerenti dei miei, chiedo: Come
mai questa differenza? Puň esserci qualche settaggio nella mia macchina
(anzi, due sistemi distinti) che giustifica i miei tempi? Grazie.

 enormi mi paiono assurde.
Dire che l'accesso dati in rete su Access è più veloce che su Sql Server
è un'assurdità concettuale.
C'è sicuramente un aspetto del test invalidante.
Mi piacerebbe dare un'occhiata anch'io al test di lupo.
ciao
ugo


Ripeto quello che ho scritto ad H.P.L.:
mi fai dare un'occhiata al progetto di prova?
ciao
ugo

 ha scritto nel messaggio
news:abilq0$lh$3...@pegasus.tiscalinet.it...

Ugo (bentornato!), sarei felice se anche tu (come ha già fatto HPL, con
risultati sorprendenti...) potessi darmi una mano a capire. Il test (credo)
è assolutamente "onesto", probabilmente dipende da parametri ambientali o
settaggi strani. Ti mando il test alla tua mail.

 mi fai dare un'occhiata al progetto di prova?
Ne sarei felice! Ti ho mandato una mail.


Ok, ricevuto.  :-)
Grazie.
Lunedě do' subito un'occhiata al progetto in ufficio
(qui non ho Sql Server...) e ti dico.
ciao
ugo

 ADO + SQL Server     0,343
Dopo essere riuscito (grazie ad Hal) a montare SQL Server 7.0, DeskTop
Version (poi aggiornato con SP2), sul mio portatile HP Celeron 1.06Ghz,
256Mb, HD 20Gb, XP pro praticamente integro e settato come da produttore, ho
rifatto la prova di apertura di un recordset di 41219 records per 7 campi (x
50 volte):
DAO+ACCESS 0.070
ADO+SQL Server 22.406
ADO+SQL Server (con select tale da restituire solo 100 records) 0.296
MSADO15.DLL versione 2.70.7713.0
Sarà qualche maledetto settaggio/protocollo/ammenicolo o merdaio in giro per
il mondo?

 news:gyVC8.40248$US3.8...@twister1.libero.it...
...
Ho mandato una mail anche a te con allegato il progetto VB per il test.
Grazie.

 ha scritto nel messaggio
news:SHeD8.45521$5k4.9...@twister2.libero.it...

Ehm, ... come non detto. Il tuo indirizzo mail non è valido e, francamente,
no riesco a comprendere quello "vero".

 (anzi, due sistemi distinti) che giustifica i miei tempi? Grazie.
lupo, perche' non ne fai un progetto per il sito comune ?
hpl, hellboy, ugo e chi si sente puo' aggiungerci qualche commento.
visto l'uso credo piu' diffuso di vb, e i db che gli si appiccicano di
solito, potrebbe essere interessante per parecchi.
ciao, a.

 ciao, a.
Lusingato! Appena ho un pelo di tempo per renderlo meno spartano
mantenendone però la semplicità e leggerezza(inserimento controllo errori,
personalizzazione e qualche ammenicolo), lo mando.

 per parecchi. ciao, a.
Io con i database ho poco a che fare e me ne intendo veramente
poco...



allora il "trucchetto" antispamming funziona davvero ;))
piccolo quiz: cosa ti suggerisce quel "SENZAFINE" tutto in maiuscolo?
cioč, un sinonimo di senzafine (hai presente quel simboletto matematico che
pare un 8 sdraiato su un lato) quale potrebbe essere? ;))
ciao

"HellBoy" <hel...@SENZAFINE.it> ha scritto nel messaggio
news:abmsbq$jd2af$1...@ID-92828.news.dfncis.de...

Hell, ieri sera c'ho pensato una decina di minuti e non m'č venuta. Era cosě
facile...
Ora ti mando lo stesso progetto che magari verrŕ poi pubblicato sul Sito
Comune.
Grazie della disponibilitŕ.

 ciao, a.
Sono stato ... rifiutato dal SC o forse ho fatto (vista l'ora) un po' di
pasticci.
Ti mando una mail col progetto. Ehm... spero che quel "
labrador.ca
" sia un
dominio vero...

 dominio vero...
lupino mio, il labrador e' effettivamente nel canada, ma e' molto piu'
facile che mi trovi come andrea punto palazzi chiocciola tin punto it.
ciao, a.

 ha scritto nel messaggio
news:abntgv$jndht$1...@ID-51318.news.dfncis.de...

Ho fatto. Grazie per quello che potrai fare.

Ho pubblicato sul SC con esito positivo (salvo le eventuali 48 ore di
attesa)
File: VBDAOADO.ZIP
Parole chiave: VBDAOADO test velocità velocita' DAO ADO database Access SQL
Server


OK.
Come promesso, ho fatto qualche test.
- Premessa:
- database mdb _in rete_  (troppo comodo testare sul disco c:   :-PPPP )
- Ado con apertura adOpenDynamic: sennò lo costringi a crearti un cursore
sul client... (non so se mi spiego)...
- Rete a 100mb libera: solo io e il mio personal e una macchina win2000
_PRO_ a fare da server
(il che, fra l'altro, peggiora le prestazioni di SqlServer che non ha
priorità di processo)
- Apertura del database Mdb effettuata da un solo utente
- tempi rilevati: minimo _senza movelast_ e massimo _con movelast_
- condizioni sql semplici:
 "Select * From RBOLCA "  - 46029 record
 "Select * From RBOLCA WHERE NUMCAR=2"  - 8538 record
 "Select * From RBOLCA WHERE NUMCAR=2 and ESERCIZIO='2000'"    - 1929 record
 "Select * From RBOLCA WHERE NUMCAR=2 and ESERCIZIO='2000' AND
NUMRIG='03'" - 209 record
DAO+MDB:
=========
- Apertura Db:
1,9 / 2.2 sec.
- Apertura recordset:
Nessuna condizione: 0.1 / 2.1 secondi
1 condizione where: 1.1 / 8,1 sec
2 condizioni where: 1,1 / 12.9 sec
3 condizioni where: 1,1 / 11,8 sec
ADO+SQLServer
=============
- Apertura Connection Ado:
1,1 / 1.2 sec.
- Apertura recordset:
nessuna condizione where: 0,2 / 0.59 sec
1 condizione where: 0,3 / 0,61 sec
2 condizioni where: 0.66 / 3.0 sec
3 condizioni where: 0.67 / 4.1 sec
Dal che si evince :
1) Dao + mdb è _sicuramente_ più performante in ambiente desktop (in
esecuzione locale, per intenderci)
2) La forte differenza di risultati tra apertura recordset dao con e senza
movelast si spiega facilmente:
- senza movelast, Jet ottimizza l'apertura del recordset connettendosi alla
tabella richiesta e attendendo ulteriori richieste elaborative
- con la movelast è "costretto" a elaborare il recordset per sapere "dove
diavolo posizionarsi"...
Da notare che in condizioni di elaborazione sql più complesse (join, query
nested, goup by etc...) i tempi di dao+mdb peggiorerebbero ulteriormente in
misura drastica. Ugualmente peggiorano in condizini diaccessi concorrenti.
Sql Server viceversa delega al server l'elaborazione dei dati e restituisce
ad ado selo il resultset finale.
3) Le prestazioni di Dao+Mdb decadono rapidamente quando si lavora in
ambiente di rete e sempre più all'aumentare degli accessi concorrenti e
delle richieste di elaborazione dei dati.
4) Le prestazioni di Ado da Voi rilevate come meno efficienti si spiegano
facilmente considerando la "forzatura" del cursore statico che
implicitamente trasferisce il recordset sul client per permettere ad ado di
elaborarlo in locale.
Tanto è vero che in tal caso si hanno tempi biblici, anche peggiori di
quelli di dao+mdb, ma non si notano differenze tra la creazione di un
recordset ado statico con e senza la movelast...
Il fatto poi che i tempi di Ado con cursori lato client siano terribili si
devono sia al tempo tecnico del trasferimento ficio di tutto il recordset
sulla rete locale, sia a tempi elaborativi veri e propri: la macchina client
è sottoposta a notevole sforzo per costruirsi in ram fisica (o virtuale!!!)
la struttura dati necessaria alle successive elaborazioni del recordset. Il
loro uso _deve_ essere oculato...
Conclusione finale:
- Lasciamo Dao alla sua storia: Ms _non_ lo supporta più: giusto tenerlo in
vita su progetti già attivi, assurdo utilizzarlo per progetti nuovi.
- Lasciamo Jet (mdb) al suo compito: ottimo per la gestione di database di
tipo desktop, si rivela assolutamente inadatto alle elaborazioni di rete
(sottolineo ancora che le prove effettuate siono state eseguite _senza_
accessi concorrenti...!!!!)
- Sql Server è un'altra cosa. Non sto ad addentrarmi sui confronti
elaborativi con un mostro sacro come Oracle, ma la scala applicativa è la
medesima: Database management ad alte prestazioni.
- Ado è supportato pienamente, ancorchè risente in parte di difetti di
specifiche di base. Che sia destinato a divenire Ado.net è vero, ma è pure
vero che tutto il mondo Ms si muove verso la piattaforma .net.  Perciò,
personalmente, continuo ad utilizzarlo sui nuovi progetti.
Spero d'aver detto tutto ed esposto il mio pensiero in modo chiaro.
Mi scuso per la prolissità...
ciao
ugo

 Come promesso, ho fatto qualche test.
Ugo, cortese, preciso ed esaustivo: un GRAZIE maiuscolo!
Ora leggerň con attenzione il tutto e ripeterň le prove cambiando il tipo di
cursore.
(Ti confesso: Non sapendo niente di ADO, ho letto due libri e qualche risma
di stampe da MSDN, e mi pareva di aver capito che il cursore Static, fra
quelli scorrevoli anche a ritroso, fosse il piů performante e piů
leggero...)
Ti farň sapere.
Ovviamente inserirň le opportune opzioni anche sul progetto che il WM (Lord)
dovrebbe pubblicare sul SC, magari con un aggiornamento.

 news:f_4D8.43499$US3.9...@twister1.libero.it...
... La tempesta dopo la quiete!
Il Dynamic è effettivamente molto veloce (anche in SQL Server), ma si
comporta (quasi) come il ForwardOnly:
Il recset è aggiornabile e scorrevole, ma è senza bookmarks, non sopporta
quindi il Clone, ma, soprattutto, restituisce sempre -1 alla richiesta del
Recordcount, come documentato (... by design) qui:
http://support.microsoft.com/default.aspx?scid=kb;EN-US;q194973
Si consiglia Static o Keyset, ma con questi si ottengono (con entrambi) quei
tempi assurdi.
Dovrò passare un tot di tempo per cercare e aggirare (potrò mai?) le
situazioni nelle quali uso Clone e Recordcount, ma sono talmente deluso che
non ne ho nemmeno voglia. Posso sfogarmi?
<sfogo>
Porca puttana, zozza, fottuta, troia, maledetta e merdosa!
</sfogo>
Ma sarà mai finita? Ci sarà mica qualche pidocchioso parametro che gli dice
che non me ne può fregar di meno di vedere le variazioni degli altri, in
modo che mi dia un recset come lo Static, ma con la velocità del Dynamic?
Eh, no, è? Contro logica, vero?!


I tempi non sono "assurdi"... sono prodotti dalla necessità di trasferire
via lan l'intero recordset dal server al client e dalla necessità per il
"Microsoft Cursor Service" di strutturarsi i recordset e le loro strutture
di gestione nella ram o, peggio, nella memoria virtuale e sui file di
appoggio della macchina client.
Perciò vale la solita regola:
1) Usa i cursori lato server per tutte le elaborazioni batch
2) usa pure cursori lato client di tipo statico per le elaborazioni che
_effettivamente_ ti servono sul client:
- il browsing dei dati (griglie assortite)
- la modifica dei dati
- Filtri e ricerche all'interno dei recordset
ma limitane le dimensioni per disegno:
Se di una tabella ("Tabella Nazioni" per esempio) già sai che al massimo
conterrà qualche centinaio di record, nulla ti vieta di gestirtela
interamente lato client.
Ma se devi elaborare l'anagrafe di Milano, quanto meno imposta dei filtri
sugli eventuali cursori lato client che devi elaborare:
"Select codfis, nome, cognome from anagrafe where cognome like 'ROSSI'" ti
restituirà comunque un recordset lato client "accettabile"
mentre una "select * from anagrafe" ti permette di farti una settimana di
ferie prima di tornare e trovare il client con l'hdd in crash...  :-PPPP
Spero di essere stato chiaro.
ciao
ugo

 news:LNfE8.60149$US3.1...@twister1.libero.it...
Ugo, io NON uso cursori lato client!
Voglio velocità, voglio i bookmarks per il Clone e voglio il Recordcount.
Con cursore lato server, tipo Static o Keyset, lock ottimistico i tempi di
ADO+ SQL Server sono inaccettabili.
Col Dynami ho la velocità ma non tutto il resto.
E' questo il massimo che posso ottenere?

 > news:LNfE8.60149$US3.1...@twister1.libero.it...
Prospetterei un'ipotetica soluzione (da verificare e approfondire):
Usando cursore lasto server e dynamic, alla proprietą RecordCount posso
ovviare con una Select Count(*) From Tabella Where.... Ho verificato ed č
piuttosto veloce.
Per il Clone propenderei per eseguire la Select iniziale su un altro
oggetto. Io non uso la Clone per scorrere il recordset clonato, ma solo per
salvarmelo e ripristinarlo.
Tutto ciņ ovviamente presume una variazione sensibile della logica e la
ricerca di tutte le occorrenza.

 E' questo il massimo che posso ottenere?
Puoi differenziare il comportamento delle varie componenti della tua
applicazione.
Ripeto: se vuoi il clone, devi trasferire le informazioni necessarie a
gestirlo
al client...
Quindi: cursori lato client e cursori statici _solo_ dove realmente servono.
ciao
ugo

 cursorlocation sul lato client i dati sono già sul tuo client...
Già, e lo comprendo, ma ho escluso l'esplicito cursore lato client per
l'abnorme lentezza che ha e il traffico di rete che produce intanto che
viene costruito e passato al client con tutti i dati. Preferisco (almeno per
ora e per partire con SQL Server) ridurre la scalabilità e lasciare che il
server buchi il suo disco con cursore lato server, ma che mi dia una
velocità operativamente accettabile con una decina di postazioni concorrenti
(con un lavoro "tosto" e continuato, se non costante)