Newsgroup: it.comp.software.database
Titolo: [SQL-2000]+[Acces2000 in FrontEnd]: Limiti di accessi contemporanei.

Mi rivolgo a chi ha avuto esperienza di accesso concorrente su rete locale
di una
istanza su SQL-Server2000 su un server con Win2000 Server o a chi ha una
risposta.
Sto effettuando il porting di un applicativo (per un call-center) da
Access2000 (.mdb condiviso)
a SQLServer-2000 (Access2000 x il FrontEnd + SQL x DBMS).
Il motivo principale è che, viste le dimensioni del DB (500mb ca.) con un
accesso concorrente
di circa 16 operatori, con le maschere esistenti (qualche sottomaschera...
ecc... ecc...) la
soluzione in essere *collassa*.
Per chi ha esperienze simili, dovendo massimizzare il numero di clients
(operatori)
(clients che usano Access2000 come FrontEnd al DB su SQL)
e implementando il DB lato server su SQLServer2k su un server del tipo:
Server biprocessore Xeon 650 (mi pare)
+ 1GbRam
+ 3 HD 10000 rpm raid 3 da18Gb l'uno
+ Lan 100 (switch)
quali suggerimenti?
(naturalmente cercando di astrarre la specifica della complessità del mio
schema concettuale...)
A che numero di clients concorrenti posso arrivare, ragionevolmente, per una
soluzione
che prevede un DB medio/incasinato?
Mi conviene sviluppare direttamente un frontend in VB6/VB.Net?
Ne avrei benefici?
Ed usare Explorer con le "pagine di accesso ai dati"? che mi dite?
(Così mi dovrei levare il problema di licenza di access2000)
Grazie &H3E8 a tutti i colleghi con maggiore esperienza e volontà di
contributo.
AgoGuz

 soluzione in essere *collassa*.
Non ci sono limiti teorici o pratici (addirittura anche usando tabelle
collegate ODBC, prestazioni inferiori a parte).
Però sei troppo generico, i motivi che possono far collassare _cioè diventa
lenta?_ tale configurazione sono molti, a partire da una progettazione
discutibile dell'applicazione.
Non puoi portare pari, pari un'applicazione da JET a SQL Server, nel secondo
caso ti devi sforzare di far lavorare il server con sql specifico.
A parte questo potresti avere problemi sul Server, ma come aiutarti in tal
senso su un ng?
Ciao.

 contributo.
Ripremetto che dubito fortemente di avere maggiore esperienza, ma ormai
sono qui... :)
Sto per affrontare un progetto simile, le uniche differenze sono che il
database è più grosso e gli utenti sono meno, e meno propensi all'acquisto
di licenze e nuovo hardware.
Dopo aver fatto alcune prove ho optato per Python + PostgreSQL sia sul
client (Windows/Linux) che sul server (Linux) utilizzando i tools
Reportlabs per la generazione di report in PDF complessi e le librerie
wxPython per l'interfaccia e la produzione di grafici + un framework
chiamato Twisted Matrix (a mio avviso semplicemente meraviglioso) sul
server. Costo licenze = 0.
Magari ti può interessare.
Ciao,
	Nicholas

 server. Costo licenze = 0.
Ma hai tutta questa libertà? E di firebird che mi dici? :)
-- 
Rhymes (rhy...@NOSPAMmyself.com)
linux registered user #219707
linux registered machine #172395

 collegate ODBC, prestazioni inferiori a parte).
I limiti teorici e pratici sono la gestione delle concorrenze se non
erro, magari ricordo male, ma Microsoft garantisce fino a un determinato
numero di utenti, forse proprio 16...
[...]
Ciao,
	Nicholas

 Magari ti può interessare.
;-) Ottima *dritta*, grazie x i consigli.

 senso su un ng?
Puoi aiutarmi se hai dovuto affrontare un porting (con successo) di una
soluzione
access97/2000 (Jet) a T-Sql.
Grazie, cmq.
AgoGuz

 numero di utenti, forse proprio 16...
Seguo da tempo (software solo in parte fatti da me) un'azienda che lavora su
configurazione simile e non ho rilevato problemi.
Peraltro non sono a conoscenza di un tale limite dichiarato da Microsoft.
Ti saluto.

 access97/2000 (Jet) a T-Sql.
Ci si potrebbe scrivere un libro.
Secondo me dovresti individuare i colli di bottiglia dell'applicazione e
postare i problemi individualmente su:
microsoft.public.it.sql
it.comp.appl.access
Ciao.

 Ma hai tutta questa libertà? E di firebird che mi dici? :)
Non è che ho tutta questa libertà: il cliente ha delle richieste che la
proposta deve soddisfare, tutto il resto sono affari miei, l'importante è
che il risultato finale sia buono.
Se il cliente non vuole spendere molto in licenze è inutile che gli
proponga Oracle su Windows 2000, mi manda giustamente a quel paese,
soprattutto quando l'alternativa è assolutamente valida e rispecchia
appieno le specifiche.
FireBird non l'ho mai usato purtroppo, adesso sono riuscito a installarmi
SapDB e voglio dargli un'occhiata (se trovo un po' di tempo).
Ciao,
	Nicholas

 Ti saluto.
Sulla FAQ del newsgroup c'è esplicitamente scritto, e mi pare abbastanza
realistico dato che si parla di accesso a un 'file' che tale gestione non
sia ai livelli di un DBMS client/server.
Ciao,
	Nicholas

 sia ai livelli di un DBMS client/server.
Forse non ci siamo spiegati: sul Server è installato SQL Server o un .mdb
condiviso?
Nel secondo caso si parla di file-sharing e ci sono limitazioni sulle
multiutenze sopportabili (255 teoriche, poche decine _o unità_ all'atto
pratico).
Io avevo inteso _evidentemente sbagliando_ che come BE si parlasse di SQL
Server.
Ciao.

 Server.
Ah, ecco :) No, da quel che ho capito il collasso si ha con un mdb
condiviso, per questo l'OP vuole portare l'applicazione su SQLServer
mantenendo Access come frontend.
Ovviamente SQLServer non ha queste limitazioni.
Ciao,
	Nicholas


Ok, infatti non era forse chiaro che attualmente il BE è implementato sul
server
con un *lurido* .mdb in file-sharing! :-O
Con questo (e Jet, evidentemente) non si riesce ad ottenere performances
accettabili.
E mi pare anche giusto, visto che devono *fisicamente* transitare 30Mb di
dati che
POI sono risolti dalle queries in *locale* sui clients!!!
Non si discute, evidentemente, sulla migliore bontà di una soluzione
client/server.
Mi chiedevo soltanto se avete mai avuto problemi di performances con questa
architettura ed un FE mediamente complesso (Access2000/VB) che poggiasse su
SQLServer.

 SQLServer.
Gli Access Data project (.ADP) nascono proprio per creare FE agganciati con
ADO a Sql Server.
Francamente non vedo limitazioni _a parte una certa complessità di sviluppo_
in multiutenza con tale architettura.
Usando drivers ODBC per connettersi al Server SQL ci vuole più pazienza per
ottenere buone performances al crescere dei posti lavoro, ma è più semplice.
Per ulteriori dettagli vedi i ng. che ti ho segnalato.
Ciao.

 ottenere buone performances al crescere dei posti lavoro, ma è più
semplice.
Si, so di cosa mi parli. Ero alla convention Microsoft a Roma intitolata
"Access97 vs Access2000: il porting".
In ogni caso, anche un .ADP alla fin fine usa una connessione .ODBC al
SQLServer,
anche se in modalità *diciamo* un pò più nativa.
Esistono limitazioni, varie, effettivamente. Non è quello che mi
preoccupa...
Mi chiedevo se avete sviluppato mai un FE Access2000 che giri su,
diciamo una 60-ina di postazioni e che poggi su un BE con SQLServer.
(All'atto pratico, non secondo quanto dice MS...) ;-)

 (All'atto pratico, non secondo quanto dice MS...) ;-)
Nel caso di cui parlavo sono trenta posti di cui la metà _mediamente_
concorrenti.
Tuttavia, ripeto, le uniche limitazioni con una configurazione .ADP sono
legate al Server SQL.
Ciao.

 anche se in modalità *diciamo* un pò più nativa.
Scusate se m'intrometto: quanto scrive Simone su .ADP e ADO è giusto, ma in
ogni caso cosa ti fa pensare che usando ODBC le prestazioni siano
automaticamente scarse?
Lavorando con tabelle collegate ODBC si ha l'irresistibile _deleteria_
tentazione di mantenere il 90% del progetto tale e quale al "fratellino"
base Jet ... in tal caso l'applicativo lavorerà pesantemente lato Client a
svantaggio della scalabilità.
Ma usando dove opportuno sql Pass through e Stored Procedures (con ODBDirect
puoi passare senza problemi parametri di input a una S.P. e valutare
parametri di ritorno) si fa lavorare il Server come Dio comanda, su questo
non ci piove.
Sforziamoci di progettare applicazioni che elaborino prevalentemente lato
Server, creiamo interfacce più semplici e razionali, usiamo con parsimonia
Features intrinsecamente costose (vedi strutture master-detail o combo a
espansione) e le prestazioni in multiutenza verranno da sole ... ODBC, ADO
2.XX, o 
ADO.NET
 che siano.
Ti saluto.


Parole sante.
Ok, grazie ancora a tutti, ;-)
ora fò un pò di test e vi terrò informati.
Saluti.
AgoGuz