Newsgroup: it.comp.appl.access
Titolo: da a2000 a2007 conviene ?

Buonasera a tutti ,
vorrei continuate a sviluppare un mio piccolo applicativo che lavora in rete 
e fatto con a2000 e relativo mdb,e passare tutto sotto a2007 e relativo 
acdb.
Secondo voi ci potrebbero essere problemi  di funzionalità e di stabilità 
per l'applicazione ?
Se si di che genere ?
Continuo con A2000 ?
Grazie per le eventuali risposte e per i suggerimenti.

 ha scritto nel messaggio 
news:489c9c80$0$1090$4faf...@reader1.news.tin.it...

Lascia perdere...
ma è una mia personale convinzione nei confronti dei prodotti micro$oft.
Devono passare almeno altri 2 anni...
Antonio 

 ha scritto nel messaggio 
news:489c9c80$0$1090$4faf...@reader1.news.tin.it...

Access 2007 è quello che mi ha convinto a passare a VB.
Naturalmente, è solo il mio punto di vista.
Ciao.
eSQueL 

 ha scritto nel messaggio 
news:by5nk.41156$Ca.1...@twister2.libero.it...

Hai fatto forse il passo troppo lungo....
Io sinceramente non sono ancora passato ad AC2007...ma AC2003 mi da molte 
soddisfazioni
Punti di vista...
Ciao
-- 
Roberto da Parma 

"Maurizio M"

Dai un'occhiata e vedi se può fare al caso tuo:
http://allenbrowne.com/Access2007.html
Ciao: Oscar

 ha scritto nel messaggio 
news:489d7512$0$1088$4faf...@reader1.news.tin.it...

Sì, punti di vista. Però, l'argomento mi sembra interessante. Personalmente, 
ho quasi terminato la migrazione in VB e, in tutta franchezza, mi sono 
rammaricato di non averlo fatto prima. Di Access mantengo il BE (un accdb 
codificato) e, almeno sino ad ora, ho trovato solo miglioramenti (a volte 
anche eclatanti).
Due note dolenti: mi son fatto abbindolare dal DataEnvironment con il 
risultato che ho perduto la settimana di lavoro guadagnata nella costruzione 
delle forms per i problemi che dà. Eliminato il DE, va come una scheggia. 
L'altra è l'ocx necessario per sostituire il DataReport che, francamente, è 
davvero scarso. Avevo messo il naso in CrystalReport ma l'ho scartato 
subito. Uso ActiveReports che mi pare una buona soluzione (anche se qualche 
problemino con la registrazione c'è).
Ciao.
eSQueL

 problemino con la registrazione c'è).
Spero tu non stia parlando del vecchio VB, diversamente tra breve dovrai
fare altra "migrazione".
Ciao: Oscar

 ha scritto nel messaggio 
news:489d89c3$0$40302$4faf...@reader5.news.tin.it...

uh ... sì, non esiste il DataEnviroment in 
VB.NET
 (almeno non mi pare). Non 
so,  non sono così convinto. Il mio vicino di casa programma ancora in COBOL 
ed i suoi figli crescono sani e nutriti :D
Beh, a parte gli scherzi, mi ci è voluto poco più di un mese per migrare. Se 
l'avessi fatto verso .NET sarei ancora al palo. Conto d'essere pronto a 
farlo di nuovo quando VB6 non lo vorrà più nessuno.
Ciao :)
eSQueL 

 farlo di nuovo quando VB6 non lo vorrà più nessuno.
Mi hai implicitamente risposto: se la "migrazione" l'hai effettuata in un
mese significa che sviluppavi giochini con Access.
I veri applicativi richiederebbero anni per la conversione a un sistema così
diverso.
E comunque, sostanzialmente, VB6 già oggi è un reperto storico tra i
professionisti.
Ciao: Oscar

 mese significa che sviluppavi giochini con Access.
mmm ... non è un giochino. Gestisce un database. Piccolo, ma pur sempre un 
database :)

 ha scritto nel messaggio 
news:Xihnk.41303$Ca.1...@twister2.libero.it...

Non entro nel merito del database ma se proprio mi dovessi spingere verso 
altri linguaggi allora sceglierei .NET....ma per il momento sto dove 
sono....
Oggi dici...
"Conto d'essere pronto a
farlo di nuovo quando VB6 non lo vorrà più nessuno."
Ci sei già vicino...pensaci...
- OCX?E qual'è il problema con Access?Supportati alla stragrande e semplici 
da integrare...
- DLL?Si integrano perfettamente....e c'è un Lebans che è una fucina....
Ora anche .NET ho scoperto all'ultima CISA che "lavora" anche per Access...
- Report?Già integrati e facilissimi da smontare e 
rimontare...creare...distruggere e ricreare...
ActiveReport?E' solo un pagliativo ad un buco di VB6...
- Velocità e rete?Credo che con SQL Server non ci siano problemi...ma tu usi 
un accdb, eh?
Anche io per il momento, ma c'è già chi è più avanti e con ottimi 
risultati...io personalmente sto tentando di interfacciarmi con 
MySQL...l'inizio non è male...e se con VB6 tu volessi cambiare 
database???Che fai riscrivi codice?Azz...
Come vedi chi più e chi meno producono per Access...io al momento non penso 
a database per multinazionali...
Ma...per tutto il resto c'è ACCESS.... :-)))
Facendo i conti... 4-0 per Access... :-))
Bella la discussione però....


 ha scritto nel messaggio 
news:Xihnk.41303$Ca.1...@twister2.libero.it...

Dimenticavo....qui gioco in casa.... ;-)


 Roberto da Parma
Eh sě, ti piace vincere facile :PP (beh, anche a me ... gh). 

Bella discussione veramente...
e' bello potere avere tanti pareri diversi e poterli esprimere e 
confrontarsi.
A eSQuel voglio dire che io al contrario della sua esperienza,per quel poco 
che riesco a programmare,ho fatto invece il passaggio inverso , sono passato 
cioè da VB6 a A2000 perchè con Access riesco a sviluppare molto più in 
fretta di VB6 tenendo presente che un progetto è composto di 
maschere,report,database,aiuti su internet,newsgroup e disponibilità 
mischiata ad una grande dose di pazienza di alcune persone che collaborano a 
questi gruppi (questo vale sia per Access che per VB).
Forse ha ragione Roberto.Nella mia situazione e con le mie (poche)conoscenze 
mi conviene passare a A2003.
O no ?.....
Ciao 

 ha scritto nel messaggio 
news:489db0b9$0$18150$4faf...@reader3.news.tin.it...

Non si tratta forse di poche conoscenze...quelle anche con Access non ti 
portano lontano...forse in nessun linguaggio.
Vero è che Access forse è più facile per per partire di tanti altri 
linguaggi...ma...anche lui da il suo bel da fare.
Per il resto ripeto, sulla base anche di quanto detto prima, credo che 
Access abbia ancora grandi margini di miglioramento.
Poi credo che nessuno nasca "imparato", ma credo anche che ognuno abbia una 
certa predisposizione per certi linguaggi.
Io non so se ho trovato il mio...ma per il momento mi sta dando tante 
soddisfazioni...e....soprattutto...da magnà....che non è poco.


 ha scritto nel messaggio 
news:489db0b9$0$18150$4faf...@reader3.news.tin.it...

Secondo me ci si dimentica un punto fondamentale; che access ti permette di 
"dimenticarti" della gestione dei dati grazie ai suoi oggetti associati, 
velocizzando lo sviluppo per arrivare a realizzare un buon 90% 
dell'applicazione. Ovviamente se l'analisi è più che buona...
Ciao.
-- 
Sergio MAZZA 

 solo miglioramenti (a volte anche eclatanti).
E sentiamo quali sarebbero questi miglioramenti eclatanti...
Saluti. 

 ha scritto nel messaggio 
news:48a13719$0$26140$5fc...@news.tiscali.it...

Siamo sul 5-0? :-)


 solo miglioramenti (a volte anche eclatanti).
Per esempio come realizzare una maschera in meno di due secondi? Un report 
in meno di tre secondi o una query di confronto in meno di 10 secondi?
Questo sě che č eclatante!
Dai eSQueL tutto dipende da cosi devi fare. Se si tratta di un gestionale, 
Access non ha rivali.
Se poi devi realizzare un'applicativo di tutt'altra natura ma che comunque 
si poggia su di una base dati, allora se ne puo parlare...di VB.
Per esempio ho dovuto realizzare un programma di balistica ed č stato 
indispensabile appoggiarmi a VB, ma se devo realizzare la gestione della 
biblioteca comunale o il magazzino dei ricambi sotto casa, la scelta sarebbe 
semplicemente obbligata: Access XP o 2007.
Ciao, Carlo 

 Ciao, Carlo
Non so. Penso di avere troppo sofferto la politica ipercommerciale che M$ ha 
fatto e fa di Office. Ma non è solo questo. I continui e spesso gravi 
problemi che Access dava (almeno a me) in fase di sviluppo (probabilmente 
dipendenti dal mio modo di sviluppare, molto disordinato in effetti) con VB 
sono assenti. (più vista corruzione delle tabelle) e, per rispondere anche a 
Simone, ho notato un sensibile incremento della velocità d'esecuzione delle 
query. Per farti un esempio, ho una form anagrafica che ad ogni scorrimento 
di record esegue sei select. Con Access era una pena, con VB viaggia 
velocissima (e il codice è esattamente lo stesso, dato che usavo ADO anche 
con Access ... conosco poco e male DAO perché ho iniziato quando è nato 
ADO).
Per quel che riguarda il mio applicativo, gestisce l'Ici. Fai conto che ho 
un'anagrafica che mediamente conta 5.000 persone e, grosso modo, 10.000 
immobili con una tabella versamenti che, compresi gli anni prescritti, 
viaggia ora sui 50.000 record.
Ciao.
eSQueL 

 viaggia ora sui 50.000 record.
Vale a dire una quantità di dati esigua, anche per gli .mdb.
Saluti.
P.S: Stai in campana con VBXX, perchè oltre a essere un prodotto poco adatto 
al gestionale, è a fine supporto.

 adatto al gestionale, è a fine supporto.
Pardon, vedo solo ora che già te l'hanno fatto notare...
Saluti. 

>
Allora, quella che segue è una delle sei funzioni chiamate in sequenza sul 
cambio di record (differiscono solo per il fatto che aprono tabelle 
diverse). Ho scelto questa tecnica perché 6 sottomaschere mica ci stavano 
:P. La tabella più grossa è quella aperta da questa funzione e il codice è 
esattamente uguale sia in Access, sia in VB ( 'cnx' in VB è aperta all'avvio 
dell'applicativo e resta aperta sino alla chiusura, mentre in access uso Set 
cnx = CurrentProject.Connection). In access le funzioni sono chiamate 
sull'evento Form_Current(), mentre in VB sia su CmdNext_Click(), sia su 
Form_KeyDown(..)
 La differenza di velocità di scorrimento è davvero notevole.
Function Versamenti(cs As String, CF As String)
On Error GoTo Err_
    Dim rs As New ADODB.Recordset
    With rs
        .CursorType = adOpenStatic
        .Open "SELECT * FROM VERS_ICI " & _
            "WHERE 
VERS_ICI.CF
=""" & CF & """;", ActiveConnection:=cnx
        If .EOF = False Then
            Me.CmdApreVers.Font.Bold = True
        Else
            Me.CmdApreVers.Font.Bold = False
        End If
        .Close
    End With
Exit_:
    Exit Function
Err_:
    rs.Close
    Resume Exit_
End Function
Ciao:)
eSQueL
P.S.: apprezzo molto la tua gentilezza e disponibilità.
 

>

E' rimasta una cs (string) che non serve più ... un esempio del mio 
disordine di sviluppatore  :) 

 P.S.: apprezzo molto la tua gentilezza e disponibilità.
Figurati, siamo qui anche per trovare soluzioni magari più performanti.
Ciao, Carlo 

> Sì, ma senza più la protezione a livello utente e con un'interfaccia 

http://img397.imageshack.us/my.php?image=anagraficaqi0.gif


Ok. Nulla da dire, semplice e con tutto quello che serve.
Immagino sia solo in visualizzazione, per l'inserimento/modifica avrai 
provveduto ad una routine apposita.
Quanto hai impiegato a fare questa maschera?
Ciao, Carlo 


 In effetti, c'è un motivo. L'unica informazione che mi necessita è l'EOF. 
Quindi, un cursore dinamico, oltre ad essere uno spreco di risorse, 
rallenterebbe l'esecuzione successiva. Infatti, devo potermi spostare nel 
recordset avanti e indietro. Per questo uso adOpenStatic (il cursore più 
veloce, forward-only, va solo avanti e sarebbe un guaio :P). 

 ha scritto nel messaggio 
news:Vblok.42393$Ca.1...@twister2.libero.it...

Ah! Nota dolente :PP
Il fatto è che quando ho iniziato la migrazione mi sono fatto fregare dal 
DataEnvironment. Ti permette di creare forms molto velocemente, ma il prezzo 
che paghi dopo è alto perché dà un sacco di problemi.
Diciamo che, compreso lo sfondo (è fatto con Corel Draw), un giorno di 
lavoro. 

 ha scritto nel 
messaggio news:g7smuc$qhm$1...@tdi.cu.mi.it...

[ops .. sbagliato post]
Nota dolente.


 lavoro.
Un giorno di lavoro compreso il codice che ci sta sotto? O solo per la 
maschera così come la si vede con tutti i controlli?
Ciao, CArlo 

 ha scritto nel 
messaggio news:g7sodt$rq9$1...@tdi.cu.mi.it...

Sì, intendo tutta quanta la migrazione dell'oggetto. Ma non posso essere 
troppo preciso per via della storia del DE che prima mi ha fatto accelerare 
e poi rallentare. Sono un migliaio di righe di codice che, però, era in 
buona parte da copiare e incollare (a parte i riferimenti a specifici 
controlli di Access e l'implementazione delle operazioni su record). Sì, 
complessivamente credo che un giorno di lavoro sia una stima verosimile.

 Roberto da Parma
Scrivendo qui non poteva essere altrimenti...
Ciao.
-- 
Sergio MAZZA 

 ha scritto nel messaggio 
news:TKlok.131394$FR.4...@twister1.libero.it...

Beh, che dire, se ti trovi bene, continua così.
Con il copia e incolla di codice e usando l'autocomposizione maschera di 
Access non dovresti impiegare più di 20 minuti, considerando che 19 li usi 
per posizionare i controlli e costruire un layout degno di questo nome.
Purtroppo hai avuto esperienze negative e questo ti ha spinto ad una sorta 
di rivincita su Access.
Usando Access dalla versione 1.1 posso solo dirti che anche io ho usato VB 
in accoppiata con tabelle mdb ma in casi veramente particolari e che Access 
rimane, a mio avviso, il tool migliore per costruire database.
Spero di rivederti su questo NG a parlare di Access.
Ciao, Carlo 

> CmdNext_Click(), sia su Form_KeyDown(..)
Dovresti pubblicare l'applicazione (o solo l'indispensabile per provare la 
maschera): quel codice è insufficiente.
Le ragioni delle performances lente potrebbero essere altre (file .ldb non 
"bloccato", autocorretc, etc).
Saluti. 

 Ciao, Carlo
Ti ringrazio. Considerato che il BE resta un accdb č probabile che ci 
incrociamo ancora :)
Ciao.
eSQueL 

 ha scritto nel messaggio 
news:48a29a1c$0$40312$4faf...@reader5.news.tin.it...

Ringrazio anche te, ma considerato che il lavoro ormai è quasi finito e che 
mi trovo bene con questa soluzione penso che andrò avanti così. Del resto, 
fra un tot sarò pronto con .Net. Così, se sarà necessario, migrerò una 
seconda volta :P
Ciao.
eSQueL migratore. 

 una seconda volta :P
Ma guarda che m'interessa zero che tu usi Access o altro: vorrei 
semplicemente (anche per curiosità) capire le ragioni di quella lentezza.
L'offerta è sempre valida...
Saluti.

 (anche se qualche problemino con la registrazione c'è).
Io da qualche tempo ho laciato il CR per usare Excel come foglio dove 
sbattere i report.
Una volta perso un poco di tempo per capire l'oggetto padre e figli con 
tutte le proprietà è il piu versatile.
--
greg