Newsgroup: it.comp.appl.access
Titolo: Transazioni in access

vorrei gestire la concorrenza (minima peraltro)al sul mio db, č
possibile attraverso le transazioni con access?
Grazie a chiunque voglia rispondermi
-- 
Posted via Mailgate.ORG Server - 
http://www.Mailgate.ORG

 possibile attraverso le transazioni con access?
Argomento complesso. Di per se, per la concorrenza non hai bisogno delle
transazioni, per certe cose ci pensa Access. Ad esempio, l'apertura dello
stesso record da parte di due persone č gestita (per i dettagli vedi
l'help).
Se invece stai pensando ai movimenti tipo conto corrente, dove devi poter
fare una serie di operazioni senza che nessuno interferisca, allora la via
giusta sono le transazioni; Access le supporta.
-- 
Jonathan Canova
www.aladinoinformatica.com

 Daniele
Piano piano....!
Vorrei capire DAO non supporta TRANZAZIONI...?? 
Se hai accessi in Multiutenza vuoi sostenere che Access(JET)
non sia in grado...??
Credo che servano dei distinguo su che tipo di Progetto
si vuole realizzare.
Access se BEN gestito riesce a garantire la Multiutenza fino
ad una decina di accessi, pur con qualche segno di rallentamento..!
Il discorso Transazioni annidate con la Multiutenza è tutto da
sviluppare e da capire cosa si intende.
La multiutenza per finire è un problema sia con Access che
con Oracle di conseguenza va gestita in ogni situazione.
ADO ti aiuta solo con l'accesso alle tabelle e il relativo
blocco record, ma con Maschere Associate vorrei vederti...!
La gestione più semplificata è con Maschere non associate,
ma in modo ottimizzato..........!
E' facile bloccare l'apertura di una Form in scrittura solo
perchè 1 Record è già utilizzato, ma questa non è Multiutenza,
è Accesso esclusivo.......che tra le altre cose fa Access...!
@Alex. 


 sviluppare e da capire cosa si intende.
Fondamentalmente sono d'accordo, però ...  la questione è ancora più
articolata.
Con un file-Server come JET i temporanei transazionali vengono creati sul
Client, non sul Server (per la semplice ragione che il motore non sa manco
quale sia il "Server").
Di conseguenza _pur migliorando le prestazioni in scrittura_ non
costituiscono un passo avanti in termini d'affidabilità o di garanzia che la
logica di scrittura sia "tutto o niente".
All'atto pratico, col vecchio Jet, tanto vale ricorrere per le scritture in
multiutenza a una semplice verifica degli errori più comuni (3260, 3197,
etc.) risparmiandosi il ricorso a delle features (le transazioni) da motore
Client-Server.
Ciao.

 Daniele
Piano piano....!
Vorrei capire DAO non supporta TRANZAZIONI...?? 
Se hai accessi in Multiutenza vuoi sostenere che Access(JET)
non sia in grado...??
Credo che servano dei distinguo su che tipo di Progetto
si vuole realizzare.
Access se BEN gestito riesce a garantire la Multiutenza fino
ad una decina di accessi, pur con qualche segno di rallentamento..!
Il discorso Transazioni annidate con la Multiutenza è tutto da
sviluppare e da capire cosa si intende.
La multiutenza per finire è un problema sia con Access che
con Oracle di conseguenza va gestita in ogni situazione.
ADO ti aiuta solo con l'accesso alle tabelle e il relativo
blocco record, ma con Maschere Associate vorrei vederti...!
La gestione più semplificata è con Maschere non associate,
ma in modo ottimizzato..........!
E' facile bloccare l'apertura di una Form in scrittura solo
perchè 1 Record è già utilizzato, ma questa non è Multiutenza,
è Accesso esclusivo.......che tra le altre cose fa Access...!
@Alex. 


 Posted via Mailgate.ORG Server - 
http://www.Mailgate.ORG
Ciao
Daniele

 Ciao.
Mi permetto inoltre di portare un'esempio stupido di come un
sistema complesso come SAP/R3, non sto parlando di noccioline...,
gestisce la MULTIUTENZA.
Saluti.


 con la gestione di azioni Transazionali...., con 10 spesso avviene...!
Beh, diciamo che se win si fosse evoluto diversamente e oggi gli impianti di
rete si configurassero prevalentemente in TServer, si sarebbe avvertita meno
l'esigenza di utilizzare SQLServer e soprattutto MSDE.
Ciao.

 O mangi la minestra... o...
Anche questo non è vero, al contrario spesso viene sconsigliato l'utilizzo
di ADO con Jet.
Per esempio:
http://support.microsoft.com/search/preview.aspx?scid=kb;en-us;Q281998
Leggi:    "Requirements for Microsoft Jet"
Con questo non voglio dire che sia sbagliato lavorare con ADO, perbacco.
Ma semplicemente farti notare che la realtà è complessa ed Access è nato
molto prima degli .ADP.
Ciao.


Solo MSDE/SQL sono in grado di eseguire le transazioni distribuite.
Contabilità, fatturazione, c'è poco da scherzare con la finanza.
Supponete di avere gli archivi su due "Mini"Server che interagiscono. Solo
le transazioni distributie ti salvano da problemi di integrità dato. Access
da solo non può farcela.
In ogni caso, e penso che lo sappiate, MSDE supportando fino a 5 client
penso che sia un ottimo compromesso.
Sinceramente dopo la mia esperienza non mi affiderei ad occhi chiusi ad un
gestionale sviluppato interamente con Jet. Finché si tratta di listini,
reportistica, pivot, marketing... va bene... ma lasciamo fare il resto a
strumenti veramente client-server.
Ciao


 raffina gli ADO è diversa rispetto a DAO... e questo succede da un bel
po'.
Scusami se non ti lascio passare nemmeno questa, ma la realtà è quella che è
... purtroppo.
Se tu avessi avuto tempo e voglia di smacchinare con .NET e 
ADO.NET
 avresti
constatato che del vecchio ADO (il 2.7 che presumibilmente tu attualmente
usi con Access) è rimasto solo il nome!
Probabilmente ci sono più differenze pratiche e concettuali (con le menate
delle modalità disconnesse) tra ADO XX e 
ADO.NET
 piuttosto che tra DAO e
ADO.
Paradossalmente ha avuto vita molto più lunga DAO di ADO 2.X!
Mai fidarsi di M$, di quello che dicono gli *esperti* italiani, di quello
che scrivono sulle pubblicazioni (e che poi magari smentiscono sulla KB).
Saluti.


Ciao
Daniele

 OLED DB SQL Server.
Non useresti mai DAO, perchè sei "di primo pelo" e credi che prima
dell'avvento degli .ADP non si potessero creare applicazioni client Server
con l'ambiente FE di Access.
Invece si può, eccome...
Saluti.

 Su .net non posso esprimere opinioni. Su 2.X le hai già lette.
Ma considerando che il futuro di ADO non sarà un'evoluzione di 2.X alcune
tue affermazioni sono perlomeno da rivedere...
Ciao.

 OLED DB SQL Server.
In aggiunta a quanto scritto prima, qualche precisazione.
Ho utilizzato files .ADP già all'epoca di Access 2000 e attualmente utilizzo
la versione 'XP per un progetto che potrebbe divenire importante.
A parte un consistente numero di bugs e stranezze, gli .ADP possono essere
una buona soluzione (di certo molto migliore di altre, anche se noto che hai
curiosi complessi d'inferiorità su microsoft.public.it.sql): forse l'unico
limite strutturale sono l'elevato numero di connessioni che aprono in
maschere complesse.
Ma è un limite che potresti sentire con centinaia di Clients concorrenti,
quindi una situazione molto lontana dalla realtà diffusa.
Una caratteristica nuova davvero notevole, per esempio, è la possibilità
d'aprire recordsets ADO e assegnarli a Runtime a qualunque oggetto, perfino
Reports ... davvero fantastico.
Questo per dire che non sono contrario a tale scelta di lavoro, anzi.
Tuttavia le macchinosità e i problemi di sviluppo non mancano: i maledetti
comandi resynk, i già citati bugs per alcuni dei quali _particolarmente
gravi_ non esistono ancora S.P, le limitazioni a livello di SQL dell'attuale
versione di SQL Server (niente query a campi incrociati, solo accrocchi).
Ma la faccenda più seccante (problema che non esisteva con A '2000) è
l'impressionante calo di performances nel caso che s'impongano dei criteri
d'ordinamento (orderby) a livello di forms.
Ecco perchè insisto: la realtà è molto complessa ... guai semplificare o a
arrivare a conclusioni affrettate.
Esistono vari metodi per creare applicazioni Client-Server, gli .ADP sono
una di tali soluzioni, non necessariamente la migliore (anche sotto il
profilo performances visto che ADO 2.xx è assai meno nativo di 
ADO.NET
).
Saluti.

 ha scritto nel messaggio
news:__L3b.274581$lK4.8...@twister1.libero.it...

Nessuno lo sa che cosa sarà di ADO. Non ho questa pretesa


Non ho detto mai detto che prima di ADP che non si potessero sviluppare
Client-Server. E' come dire che ODBC non è mai esistito. Dico che gli
accrocchi con DAO sono più dispendiosi in termini di tempi sviluppo rispetto
adli ADO/ADP.
Qualche post prima ti avevo ribadito e come mi hai scritto poco fa, la
possibilitare di assegnare a runtime i recordset in una maschera/report o in
un controllo qualsiasi.
In .adp forse sono più sbarbatello, per il resto sono anni che ci lavoro.
Ad ogni modo ADO e DAO hanno bisogno di OLE DB -> ODBC e il circuito si
chiude sempre allo stesso punto... e ci diciamo le stesse cose.
Lasciando stare per assurdo ODBC che conclusioni dai? Le immagino
Ciao

 Nessuno lo sa che cosa sarà di ADO. Non ho questa pretesa
Come nessuno lo sa?
E' evidente che sarà .NET!
Saluti.

 tratta di un errore di battitura "ha" invece di "hai"?
Mi riferivo al TH "usate Access come FE" che mi pareva avessi aperto tu.
Forse mi sbaglio.
Ciao.

 Ciao.
Il mio era "non usare Access come FE?" e si basava su una svista di qualcuno
che ha pensato di scrivere su una pagina web una cosa molto superficiale.
L'ho scoperto solo dopo.

 ha scritto nel messaggio
news:upE4b.281298$Ny5.8...@twister2.libero.it...

Filosofeggiavo sul dopo .net...

 Lasciando stare per assurdo ODBC che conclusioni dai? Le immagino
Scusa, senza ODBC è chiaro che DAO consente solo di creare applicazioni JET.
Però non stiamo ragionanzo per assurdo  ;-)
Saluti.

 L'ho scoperto solo dopo.
Perň denota una certa insicurezza da parte tua...
Comunque il post ha attirato come il miele con le mosche, un ignorante
coglione che ancora non ha mollato la presa!
Saluti.


Non è insicurezza... è essere pronti a mettersi in discussione e in continua
ricerca di informazioni e su questo vedo che concordi.

 costeso di lavoro.
ADO vs DAO su files .mdb non ha molto senso.
Per il semplice fatto (come anche M$ ammette dal link che ti postavo) che
DAO è la soluzione più specifica e performante per il motore JET.
Ma c'è un altro fatto assai importante: anche se M$ ha rimosso dagli Help i
riferimenti a DAO, di fatto è impossibile creare un'applicazione Access+Jet
solo con ADO.
Le tabelle collegate _anche allegate con codice ADO_ continuano a essere
basate su recordsets DAO!
Quindi, al massimo, si potrebbe creare un'applicazione mista che utilizzi
ADO per i recordsets aperti esplicitamente, ma di fatto tutto il resto
rimarrebbe DAO.
L'unico possibilità di usare solo ADO in un .mdb sarebbe NON usare tabelle
collegate.
C'è un problema tuttavia: solo in un .ADP puoi assegnare "al volo" un
recordset ADO come origine dati di un Report...
Saluti.