Newsgroup: it.comp.appl.access
Titolo: 1.400.000 Nominativi. COME PESANO!!!!

Risolto il problema dell'ID ora sorge l'ancor più grave problema di come
farli muovere.
Mi spiego meglio, pesano da morire. Pesano a tal punto che mi inchiodano la
macchina.
Premesso che non posso dividerli ne per Categoria ne per Cap o Zona, avete
qualche idea su come alleggerire il tutto visto che il db è correlato con 2
sole tabelle?
Devo poterli gestire in modo semplice visto che devono essere contattati uno
ad uno telefonicamente.
Come fanno alcune aziende a gestire non centinaia ma milioni di informazioni
senza avere il mio problema?
Grazie Marco M.

> Semplicemente non usano Access e un pc ma piuttosto un bell'AS400 ( il mio
Semplicemente per te; cosa è AS400 ?
Comunque non credo sia impossibile, migliorare le prestazioni, l'importante
è sapere come.
Ciao Marco M.

 Semplicemente per te; cosa è AS400 ?
AS400 e' uno strumento grazie al quale la IBM ha fatto tanti soldi e
coninuera' a farne e a farne fare ai quattro programmatori disposti a
scornarcisi (inteso nel senso di spendere fatica) fino a quando i clienti
capiranno di pagare troppo per ottenere poco
Il nonno mi scusera', ma ho dovuto subire per anni le "angherie" di un
programmatore di as400 che non ha mai capito che quello che lui faceva in
una settimana con altri strumenti si faceva in mezza giornata.
Ciao, Sib
PS comunque ognuno e' libero, chiaramente, di avere le proprie opinioni
--
------------------------------------------------------
Non e' grave non capire; grave e' occuparsi di cio' che non si capisce.
Ma ricordate anche che il saggio egizio Ptahhotep scrisse:
"... perche' non esistono saggi per nascita."
------------------------------------------------------
Saturiamo ECHELON:
bomba saddam attentato medio oriente


senza avere il mio problema?
Marco, con tutta probabilità le aziende a cui fai riferimento utilizzano
ben altro sw/hw, non tengono certo gli archivi su un pc+access.
Cmq, a far cosa esattamente ti decadono le prestazioni ?
Non è detto che non si possa tentare qualche raffinamento....
Bye, Ste

generalmente ci si aiuta con le chiavi, poi stando attenti ad accedere ai
record in modo da filtrare il più possibile il recordset che si intende
visualizzare ad esempio non aprendo mai direttamente la tabella ma accedendo
trammite query magari parametrizzate.
ad ogni modo visto le dimensioni pensare ad un sistema Client-Server è
sicuramente di aiuto anche senza arrivare a dissanguarsi con un AS400 puoi
valutare altri sistemi come SQL-Server, ORACLE o informix che essendo dei
sistemi di gestione di database permettono di avere vantaggi non solo sulla
gestione da programma ma anche un più valido approccio anche per i
salvataggi la replica dei dati e l'utilizzo in multiutente.
Rodolfo.

Si parametrizzarsi va anche bene, ma a me servono solo un paio di tabelle da
relazionare tra di loro.
TabellaClienti e TabellaChiamate i tutto gestito da una Maschera con
Sottomaschera.
Ora tenendo in considerazione che la macchina da me usata è ottima non
capisco perchè una semplice casella combinata con una banalissima istruzione
SQL su origine riga per il filtraggio dei clienti da scegliere, possa
rallentare al punto di dover rinunciare ad operare.
Forse c'è una soluzione a me ignota
Ditemi di si
Grazie per qualsiasi suggerimento Marco M.
Ci sarà pure una via di uscita, magari anche ingegnosa.

 wrote in message 85j7c3$le1$1...@nslave2.tin.it...

Ciao io ho dovuto rinunciare alle caselle combinate con tabelle
che arrivano a circa 10.000 elementi ... non c'è stato niente da fare
si bloccavano spesso l'applicativo. Sul manuale di programmazione Jackson
ho trovato un "bel" consiglio, condiviso anche dalla microsoft press, ovvero
non usare le caselle combinate per piu di 100 elementi con applicativi
multiuser in rete ...
Adesso, prima di passare a SQL Server, sto sperimentando la gestione delle
repliche ... se i dati sono semistatici .. teoricamente dovrebbe funzionare.
In questo
modo il carico di lavoro dovrebbe pesare sul client ...
Che ne dite ?
Ciao Sting70

una settimana con altri strumenti si faceva in mezza giornata.
Sì, ma poi probabilmente ogni due giorni si piantava, e non per colpa
del programmatore, ma per un conflitto di memoria o per un "errore
irreversibile" o una patch non applicata, o per una patch applicata o
chissa per quale altro motivo legato alla scarsa stabilità
dell'ambiente.
Dimenticavo: AS/400 era Y2K compliant già nel lontano '95, mentre Win
95 lo è diventato (ma ne siamo proprio sicuri ?) solo pochi mesi fa...
Ah, già ! Chissà come mai il sistema informativo al quartier generale
di MS è su AS/400 ?
Vincenzo Turturro
----------------------------------
Niuna impresa, per minima che sia, 
può avere cominciamento e fine
senza queste tre cose:
e cioè senza sapere,
senza potere,
senza con amore volere
(Anonimo fiorentino, XIV sec.)
------------------------------


Se è per questo ricordo che fino a qualche anno fa la BBS di MS-Italia
girava su OS/2, ed il progetto era già della sola ibm da un sacco
di tempo!! (NT c'era già)
Bye, Ste

 (.....)
In definitiva credo che si debba prendere il meglio che c'è da tutti
gli ambienti; non è un caso che AS/400 venga ormai venduto di default
con la scheda Ethernet.



Eccheccavolo....
A questi prezzi stracciati ne voglio uno da mettere
sulla scrivania ! Evidentemente sono da troppo
tempo lontano dal mondo ibm, non ero a conoscenza
del fatto che si son messi a far saldi pure loro.
Il + piccolino è ancora delle dimensioni di un
frigorifero o sono riusciti a miniaturizzarli
un po' ?
Bye, Ste



per quanto riguarda le caselle combinate io quando superano il migliaio di
elementi ed è uyilizzata in multiutenza ho utilizzato questo sistema:
creo un campo di tre caratteri indicizzato nella tabella in questione
valorizzo il campo con i primi tre caratteri del campo utilizzato pre
l'ordinamento o la ricerca poi nella maschera prima della casella combinata
metto un controllo dove l'utilizzatore dovrà inserire i primi tre caratteri
di ciò che dovrà contenere la casella combinata su uscita o su modifica
della  controllo eseguo  la requery della casella combinata dove
nell'origine dati la select avrà una condizione del tipo ( where
[nominativo] like me![controllo1] & "%" ) in questo modo se il programma è
in rete evito anche di far transitare enormi quantità di dati senza che
nessuno in realtà poi li utilizzi.
rodolfo

Praticamente è impossibile applicare qualsivoglia filtro.
Esempio Combo sui clienti impossibile, ......
Il file creato è troppo grosso 220 MB e considera che ci sono solo dati.
Che delusione, figuriamoci se comincio a inserirvi altre informazioni sul
contatto telefonico!
Grazie Marco M.

Il problema sorge quando cerco di applicare un qualsivoglia filtro.
Una Combo sui Clienti è impossibile nemmeno si apre.
Quello che non capisco è come si possa essere arrivati ad un file di 220 MB
con un paio di tabelle di cui solo una composta da dei banalissimi dati.
Grazie Marco M.


Non male come idea, specifica meglio se puoi?
Ciao Marco M.

...

Tanto per cominciare inizia con applicare il parametro /decompile
e poi a fare una compattazione (guarda sul sito comune la faq
sul db diet plan).
Poi bisognerebbe  dare una occhiata alla struttura del db
(campi, tipi di dato, indici), inoltre i "filtri" sono una porcata,
in genere è infinitamente preferibile aprire un set di record
con **solo i record** che occorrono (sql dinamico).
Comincia a compattare e facci sapere la struttura delle tabs....
Bye, Ste

 Comincia a compattare e facci sapere la struttura delle tabs....
Provo e vi informo
Grazie Marco M.

Ho provato a limitare similmente a te il num. di records , ci si riesce però
:
Il problema è nato quando ci possono essere più righe . Se la prima l'hai
scelta in base a "ABC" e la seconda la vuoi scegliere in base a tutti quelli
che iniziano con "def" , vedrai che la riga precedente (sulla
casellacombinata) non conterrà valore , correggimi se sbaglio , ma prima
prova .
Ciao , rispondimi .


 > (.....)
Tanto, ma proprio tanto meno, e non parlando di assemblati, ma di server HP
con HD SCSI in RAID 1 e doppio processore.
Per non parlare del fatto che quando si arriva a questi livelli non si parla
piu' di giocattoli come Win95 o peggio 98, ma di WinNT Server (un po' piu'
stabile direi)
Tra parentesi il server HP più piccolo gestisce fino a 60 utenti
E' chiaro che il SW non sarà access se gli utenti contemporanei sono più di
5/6 o se il db è da grande magazzino, ma non e' quello lo scopo per cui fu'
creato, access e' stato fatto per le piccole imprese e gli studi
professionali (chiaramente).
Ciao, Sib


Naturalmente ogni tanto partono queste dispute tra i vari ambienti che
di solito creano discussioni lunghe animatittissime e quant'altro.
Per anni ho lavorato su PC, MVS, VMS e, limitatamente su AS400 e
sistemi 36 e 38.
Per paragonare i vari ambienti e' chiaro che occorrerebbe conoscerli
tutti nel dettaglio e penso non esista uno sulla terra in grado di
farlo.
Chiaramente le valutazioni possono quindi essere unicamente di
carattere generale.
Tutti gli ambienti proprietari MVS, AS400 e lo stesso Mec godono della
fama di ambienti stabili.
E' chiaro che se io sono un costruttore di PC che obbliga le scelte
hardware dell'utente su miei prodotti faccio molto presto a verificare
la maggior parte delle possibili configurazioni e la stabilita' dei
drivers.
A mio parere e' possibile ottenere configurazioni stabili su qualsiasi
S.O. purche' ci sia uno che si renda responsabile di tale stabilita'
eventualmente obbligando anche le scelte hardware.
Penso nessuno metta in dubbio la stabilita' per es. di macchine server
per es. allestite da HP su NT.
Quindi conta chi le prepara e le gestisce.
Operare su ambienti proprietari obbliga spesso a non pote utilizzare
tutto cio' che giorno per giorno il mercato hardware sforna.
Nel caso AS400 l'adozione di Token Ring e' stata per lungo tempo se
non imposta caldamente consigliata, quando gia' il mercato aveva preso
un'altra strada.
L'ambiente di sviluppo RPG che che se ne dica per anni e' stato un
ambiente di sviluppo pessimo, disorganico ecc.ecc.
L'interfaccia assolutamente non paragonavile alla piu' sfigata delle
interfacce grafiche.
Penso che l'AS400 e'vissuto e continua tuttora non tanto per
l'ambiente operativo quanto per la qualita' delle soluzioni software
gestionali su di esso implementate.
Previsione, a mio parere sopravvivera' come server e database/server
con tanti client windows in emulazione terminale.
Stesso ruolo (a mio parere anche migliore) lo puo' offrire un buon
database server su NT o Unix/Linux.
Al momento a mio parere Linux manca pero' di un buon Database Server
con adeguato supporto.
Il cliente non cambiera' con altri ambienti solo perche' il software
rendera' il cambiamento quasi improponibile.
----------------------------------------------------------
Paolo Hölzl
Gruppo Tekup Software developer (Bologna)
----------------------------------------------------------
ATTENTION!, antispam 
For reply, substitute xxx with gruppotekup

 rendera' il cambiamento quasi improponibile
Gentile Sig. Holzl, mi trovo d'accordo con lei.
Io non ho esperienze diretta di AS400, questo e' assolutamente vero, ma ho
lavorato per anni in una azienda che operava con AS400 (ricordo ancora
quello che si favoleggiava sui compensi dello sviluppatore che, per inciso,
non era neanche part time ma prendeva il doppio di me).
Quando, con Access 2.0, io impiegavo 2 minuti a fare una query, ricordo che,
ammesso che quando serviva fosse disponibile, il programmatore AS impiegava
non poca fatica.
Ma, per favore, non tiriamo in ballo il discorso di quanti dati puo' gestire
AS400 rispetto ad Access, perche' e' ovvio che access e' stato creato per le
piccole imprese e gli studi professionali, dove i dati possono essere
consistenti ma non fenomenali e gli utenti non sono tanti.
Ciao, Sib

Al momento a mio parere Linux manca pero' di un buon Database Server
Non ho capito bene se č un tuo parere? :))))
Paolo

Io avevo un database di 20 MB , dopo la compattazione é passato a 580
KB.
Non so se il problema rimane , xché io avevo solo 600 Record.
Ciao Nicola

 wrote in message
388C0FB4...@ti-edu.ch...
