Transazioni in access
Enrico
possibile attraverso le transazioni con access?
Grazie a chiunque voglia rispondermi
--
Posted via Mailgate.ORG Server - http://www.Mailgate.ORG
Jonathan Canova
news:52a8f70b25b493e3f06...@mygate.mailgate.org...
> vorrei gestire la concorrenza (minima peraltro)al sul mio db, č
> 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
Alessandro Baraldi
news:pUi3b.270840$Ny5.8...@twister2.libero.it
>
> "Enrico" <e.zo...@virgilio.it> ha scritto nel messaggio
> news:52a8f70b25b493e3f06...@mygate.mailgate.org...
> > 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
> Il motore Jet è nato come DB desktop. Devi usare gli ADO che supportano le
> transazioni (anche nidificate... dipende dal provider dati) e se gli utenti
> sono più di due-tre sei costretto a buttarti su MSDE. E' un grosso salto di
> qualità... e di lavoro!
> 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.
Simone Calligaris
"Alessandro Baraldi" >
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.
Vero, soprattutto con i servizi Terminal...
> Il discorso Transazioni annidate con la Multiutenza è tutto da
> 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.
Alessandro Baraldi
>
> "Enrico" <e.zo...@virgilio.it> ha scritto nel messaggio
> news:52a8f70b25b493e3f06...@mygate.mailgate.org...
> > 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
> Il motore Jet è nato come DB desktop. Devi usare gli ADO che supportano le
> transazioni (anche nidificate... dipende dal provider dati) e se gli utenti
> sono più di due-tre sei costretto a buttarti su MSDE. E' un grosso salto di
> qualità... e di lavoro!
> 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.
OneEDP
> Piano piano....!
> Vorrei capire DAO non supporta TRANZAZIONI...??
Certo che le supporta.
> 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..!
Ripeto Access è nato e ottimizzato come DB Desktop, non è nato per la
multiutenza.
Per un discorso economico si può spingere l'uso fino a 10 utenti, ma i
problemi cresceranno in modo esponenziale al crescere del DB e dl numero
degli utenti. Certo è simpaticissimo vedere sullo schermo un record appena
modificato da un altro utente...
> Il discorso Transazioni annidate con la Multiutenza è tutto da
> sviluppare e da capire cosa si intende.
Le transazioni nidificate servono a mio parere a ad assicurare l'integrità
dei dati riducendo il numero dei blocchi al minimo possibile in modo che
risorse inutili vengano impegnate... e gli altri utenti sono più contenti
> 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...!
>
Non hai mai assegnato un ADODB.Recordset ad una form all'evento Load?
Puoi impostare diversi tipi di blocco a seconda della proprietà
CursorLocation della connessione (adUseClient, asUseServer) che ti risolve
il dilemma se utilizzare query asincrone o meno.
ADO è il passaggio obbligato alla multiutenza in Access per progetti di
dimensioni maggiori. Per ovvie ragioni commerciali M$ costringe all'uso di
ADO perché è l'unico mezzo che avrai a disposizione per interfacciare i
progetti ADP con MSDE/SQL.
DAO e ADO possono convivere benissimo, ma con ruoli ben distinti. Ad esempio
per comodità potrei usare ADO per le interrogazioni dal Server e DAO per
raffinare i dati "importati" su un file MDB. Ma M$ non perde occasione nelle
sue pubblicazioni a sconsigliarne l'uso. Anche perché la cura con cui
raffina gli ADO è diversa rispetto a DAO... e questo succede da un bel po'.
O mangi la minestra... o...
>
> @Alex.
>
>
> --
> Posted via Mailgate.ORG Server - http://www.Mailgate.ORG
Ciao
Daniele
Alessandro Baraldi
news:77l3b.271176$Ny5.8...@twister2.libero.it
[CUT]
> Fondamentalmente sono d'accordo, però ... la questione è ancora più
> articolata.
Si verissimo, l'ho premesso....!
> 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".
Vero, ma di cosa stiamo parlando...??
Nel senso è un gestionale VERO..?? Allora le cose cambiano,
abbiamo scherzato con questi discorsi......!!
Se invece è un Progetto limitato per il quale si può ipotizzare
l'utilizzo d JET forse è addirittura inutile eccedere nella filosofia.
Come dicevo basta ottimizzarlo.
Questo però è il problema più importante che spinge molti ad usare
SQL_SERVER o MSDE e dire che questi risolvono tutti i problemi della
vita dei Gestionali e che JET serve solo se in Local e Monoutenza....!
La realtà è che far lavorare SQL_SERVER con 10 Utenti e 1500 sono
cose ben diverse, con 1500 non puoi permetterti di essere superficiale
con la gestione di azioni Transazionali...., con 10 spesso avviene...!
> 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.
Sacro santa verità, con qualche accorgimento e poco lavoro in più
si possono addirittura evitare....!
> 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.
Simone Calligaris
"Alessandro Baraldi"
> Vero, ma di cosa stiamo parlando...??
> Nel senso è un gestionale VERO..?? Allora le cose cambiano,
> abbiamo scherzato con questi discorsi......!!
Certo che stiamo parlando di un gestionale vero.
Alessandro, se ti dicessi che il 90% delle aziende italiane lavorano con
meno di tre Clients?
La realtà in cui tu lavori non è rappresentativa, oggi, in Italia ;-)
> Se invece è un Progetto limitato per il quale si può ipotizzare
> l'utilizzo d JET forse è addirittura inutile eccedere nella filosofia.
> Come dicevo basta ottimizzarlo.
> Questo però è il problema più importante che spinge molti ad usare
> SQL_SERVER o MSDE e dire che questi risolvono tutti i problemi della
> vita dei Gestionali e che JET serve solo se in Local e Monoutenza....!
> La realtà è che far lavorare SQL_SERVER con 10 Utenti e 1500 sono
> cose ben diverse, con 1500 non puoi permetterti di essere superficiale
> 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.
Simone Calligaris
"OneEDP" <
> Ripeto Access è nato e ottimizzato come DB Desktop, non è nato per la
> multiutenza.
Qui si sta facendo confusione.
JET è basato su architettura File-Sharing, da qui nascono ovvi limiti in
regimi multiutenti spinti, come altri noti suoi predecessori (XBase,
Paradox, etc.)
Ma che non sia concepito *anche* per la multiutenza è un'affermazione _degna
di un commerciale di MS Italia adibito alla vendita di SqlServer_
semplicemente contro l'evidenza dei fatti.
Peraltro le caratteristiche multiutenti di Jet sono davvero notevoli in
ambito File-Server.
> ADO è il passaggio obbligato alla multiutenza in Access per progetti di
> dimensioni maggiori. Per ovvie ragioni commerciali M$ costringe all'uso di
> ADO perché è l'unico mezzo che avrai a disposizione per interfacciare i
> progetti ADP con MSDE/SQL.
Anche questo non è vero.
Esistono molti modi di creare con DAO/ODBC applicazioni multiutenti *vere*.
Magari (forse) meno scalabili rispetto a un .ADP, ma comunque veri progetti
Client-Server.
Inoltre MS non costringe affatto all'utilizzo di ADO, tanto è vero che A
'2003 continua bellamente a supportare DAO.
D'altro canto niente DAO, niente accessi ODBC a tutti i motori Client-Server
del pianeta.
Niente accesso multidatabase ... beh, a questo punto dovranno cambiar nome
ad ACCESS ;-))
> DAO e ADO possono convivere benissimo, ma con ruoli ben distinti. Ad
esempio
> per comodità potrei usare ADO per le interrogazioni dal Server e DAO per
> raffinare i dati "importati" su un file MDB. Ma M$ non perde occasione
nelle
> sue pubblicazioni a sconsigliarne l'uso. Anche perché la cura con cui
> raffina gli ADO è diversa rispetto a DAO... e questo succede da un bel
po'.
> 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.
OneEDP
"Simone Calligaris" <simo...@libero.it> ha scritto nel messaggio
news:Tro3b.271786$Ny5.8...@twister2.libero.it...
>
> "Alessandro Baraldi"
>
> > Vero, ma di cosa stiamo parlando...??
> > Nel senso è un gestionale VERO..?? Allora le cose cambiano,
> > abbiamo scherzato con questi discorsi......!!
>
> Certo che stiamo parlando di un gestionale vero.
> Alessandro, se ti dicessi che il 90% delle aziende italiane lavorano con
> meno di tre Clients?
>
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
Simone Calligaris
"OneEDP"
. Anche perché la cura con cui
> 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.
OneEDP
"Simone Calligaris" <simo...@libero.it> ha scritto nel messaggio
news:zQo3b.271623$lK4.8...@twister1.libero.it...
>
> "OneEDP"
>
> . Anche perché la cura con cui
> > 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!
>
Su .net non posso esprimere opinioni. Su 2.X le hai già lette.
> Mai fidarsi di M$, di quello che dicono gli *esperti* italiani, di quello
> che scrivono sulle pubblicazioni (e che poi magari smentiscono sulla KB).
>
Sono d'accordo.
> Saluti.
>
>
Ciao
Daniele
Simone Calligaris
"OneEDP"
> E' un discorso di pigrizia mentale (colpevole più M$). Se ADO e DAO fanno
> cose separate possono convivere benissimo, i ruoli ripeto devono essere
ben
> distinti. Negli ADP lasciamo fare ad ADO le interrogazioni sul server. Non
> si può chiedere a chi vanta anni di esperienza con DAO di fare finta che
non
> esiste più (un po' quello che sta succedendo con ADO 2.x e ADO.NET).
E' questo concetto di ruoli distinti che è scorretto.
In aree ODBCDirect (che sfrutti in un normalissimo .mdb privo di riferimenti
ad ADO) puoi eseguire traquillamente interrogazioni Client.Server.
> > 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.
> Te la sentiresti di affidare ad occhi chiusi a Jet le transazioni
> distribuite?
Transazioni in aree ODBCDirect?
Non vedo nulla di strano o sconvolgente!
> Te la sentiresti di dire all'utente che si trova a centinaia di chilometri
> con una banda da 50k: "Scusami se Jet si importa migliaia di record prima
di
> visualizzarti un'anagrafica... è colpa di M$"
Scusami, credevo d'esser stato chiaro quando parlavo di DAO/ODBC.
Esistono vari modi per far lavorare il Server SQL (pass-trought, ODBCDirect)
restituendo solo i risultati al client.
Ed esistono procedure Client-Server della madonna _non voglio far
pubblicità, ma se insisti_ che lavorano anche in remoto basate su tale
configurazione.
> Io non userei mai DAO per applicazioni client-server di un certo livello
> vuoi per dittatura M$ vuoi perché i progetti ADP via OLE DB usano comunque
> connessione ADO utilizzando i "meta" provider MSDataShape il quale punterà
> 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.
Simone Calligaris
"OneEDP" <
> 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.
Simone Calligaris
"OneEDP" <
> Io non userei mai DAO per applicazioni client-server di un certo livello
> vuoi per dittatura M$ vuoi perché i progetti ADP via OLE DB usano comunque
> connessione ADO utilizzando i "meta" provider MSDataShape il quale punterà
> 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.
OneEDP
OneEDP
"Simone Calligaris" <simo...@libero.it> ha scritto nel messaggio
news:WZL3b.274578$lK4.8...@twister1.libero.it...
>
> "OneEDP"
>
> > E' un discorso di pigrizia mentale (colpevole più M$). Se ADO e DAO
fanno
> > cose separate possono convivere benissimo, i ruoli ripeto devono essere
> ben
> > distinti. Negli ADP lasciamo fare ad ADO le interrogazioni sul server.
Non
> > si può chiedere a chi vanta anni di esperienza con DAO di fare finta che
> non
> > esiste più (un po' quello che sta succedendo con ADO 2.x e ADO.NET).
>
> E' questo concetto di ruoli distinti che è scorretto.
> In aree ODBCDirect (che sfrutti in un normalissimo .mdb privo di
riferimenti
> ad ADO) puoi eseguire traquillamente interrogazioni Client.Server.
>
> > > 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.
>
> > Te la sentiresti di affidare ad occhi chiusi a Jet le transazioni
> > distribuite?
>
> Transazioni in aree ODBCDirect?
> Non vedo nulla di strano o sconvolgente!
>
Dimmi sinceramente la tua opinione: te la sentiresti di affidare
un'operazione che coinvolge più server per completare un'unica trasnsazione
(ossia transazioni distribuite)? Come si comporta la commit/rollback sui
vari server? Te lo chiedo perché non ho idea come avvenga con DAO/ODBC.
> > Te la sentiresti di dire all'utente che si trova a centinaia di
chilometri
> > con una banda da 50k: "Scusami se Jet si importa migliaia di record
prima
> di
> > visualizzarti un'anagrafica... è colpa di M$"
>
> Scusami, credevo d'esser stato chiaro quando parlavo di DAO/ODBC.
> Esistono vari modi per far lavorare il Server SQL (pass-trought,
ODBCDirect)
> restituendo solo i risultati al client.
E qui mi trovi d'accordo. Quando parlavo di DAO lo assegnavo (per
semplicità) al solo motore Jet su tabelle native di Access. E' su questo
tipo che sono sfavorevole. Io preferisco usare un ambiente il più possibile
"eterogeneo" come quello dei progetti ADP.
Personalmente uso le pass-through in modo massiccio su DB2/400. Devo dire
che non sono molto contento delle prestazioni.
Sarà colpa dell'As/400... dei driver ODBC... e altro ancora.
> Ed esistono procedure Client-Server della madonna _non voglio far
> pubblicità, ma se insisti_ che lavorano anche in remoto basate su tale
> configurazione.
>
Mi baso su quello che ho vissuto sulla pelle.
> > Io non userei mai DAO per applicazioni client-server di un certo livello
> > vuoi per dittatura M$ vuoi perché i progetti ADP via OLE DB usano
comunque
> > connessione ADO utilizzando i "meta" provider MSDataShape il quale
punterà
> > 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.
>
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
OneEDP
> 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).
Comunque meglio del filesharing
> 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.
A quel punto entrano in gioco altri fattori tecnico/economici e non solo.
> 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).
>
Chi ha esperienza in Access e vuole continuare ad usarlo come FE per
progetti di grandi dimensioni non è che poi abbia tante scelte. Non potrei
fare a meno delle potenzialità offerte da Access. Non mi sognereri ad
esempio di reiventare in un X linguaggio tutta l'interfaccia utente, la
reportistica, gli eveni e quant'altro.
O .ADP o... o cosa? Tabelle collegate e query pass-through? No grazie ho
pagato già lo scotto con DB2... ma non do la colpa nè a DB2 nè ad Access.
Certo... se non si vuole usare SQL Server... è un'altra storia. La decisione
non è semplice.
Prima di salutarti dimmi cosa intenti per "complessi di inferiorità". Si
tratta di un errore di battitura "ha" invece di "hai"?
Ciao
Daniele
>
>
>
Simone Calligaris
"OneEDP" <
> >
> Nessuno lo sa che cosa sarà di ADO. Non ho questa pretesa
Come nessuno lo sa?
E' evidente che sarà .NET!
Saluti.
Simone Calligaris
"OneEDP"
> "Campi incrociati"
> Comunque meglio del filesharing
Se risolvi i problemi è meglio del filesharing!
> > 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).
> Chi ha esperienza in Access e vuole continuare ad usarlo come FE per
> progetti di grandi dimensioni non è che poi abbia tante scelte. Non potrei
> fare a meno delle potenzialità offerte da Access. Non mi sognereri ad
> esempio di reiventare in un X linguaggio tutta l'interfaccia utente, la
> reportistica, gli eveni e quant'altro.
Vero.
> O .ADP o... o cosa? Tabelle collegate e query pass-through? No grazie ho
> pagato già lo scotto con DB2... ma non do la colpa nè a DB2 nè ad Access.
> Certo... se non si vuole usare SQL Server... è un'altra storia. La
decisione
> non è semplice.
Evidentemente non hai saputo sfruttare gli strumenti a disposizione (non ho
parlato solo di Pass-Through).
Devo anche dire di non aver mai utilizzato DB2.
> Prima di salutarti dimmi cosa intenti per "complessi di inferiorità". Si
> 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.
OneEDP
> Mi riferivo al TH "usate Access come FE" che mi pareva avessi aperto tu.
> Forse mi sbaglio.
>
> Ciao.
che ha pensato di scrivere su una pagina web una cosa molto superficiale.
L'ho scoperto solo dopo.
OneEDP
Simone Calligaris
"OneEDP"
> > Transazioni in aree ODBCDirect?
> > Non vedo nulla di strano o sconvolgente!
> Dimmi sinceramente la tua opinione: te la sentiresti di affidare
> un'operazione che coinvolge più server per completare un'unica
trasnsazione
> (ossia transazioni distribuite)? Come si comporta la commit/rollback sui
> vari server? Te lo chiedo perché non ho idea come avvenga con DAO/ODBC.
Nei software che abbiamo scritto prima dell'avvento degli .ADP (e che si
continua a mantenere) praticamente tutti gli Update facevano ricorso a
Transazioni.
Però il discorso di transazioni distribuite mi è nuovo: ma scusa, in che
ambito lavori, un ente pubblico con 500 Clients in rete? ;-)
> > Esistono vari modi per far lavorare il Server SQL (pass-trought,
> ODBCDirect)
> > restituendo solo i risultati al client.
> E qui mi trovi d'accordo. Quando parlavo di DAO lo assegnavo (per
> semplicità) al solo motore Jet su tabelle native di Access. E' su questo
> tipo che sono sfavorevole. Io preferisco usare un ambiente il più
possibile
> "eterogeneo" come quello dei progetti ADP.
Adesso mi offendi: secondo te avrei sostenuto un TH sul confronto tra Jet e
SQLServer?
Comunque non dimentichiamo che gli .ADP nascono per lavorare esclusivamente
con SQLServer.
Sono una soluzione nativa senza compromessi, ma poco flessibili.
Avrai notato, per esempio, che molti Accessisti usano MySQL come BE
attraverso ODBC ... e con buoni risultati.
Con gli .ADP si potrebbe al limite aprire recordsets ADO e assegnarli
sistematicamente a Runtime ai vari oggetti.
Ma a parte che la programmazione diventerebbe macchinosa, credo che molti
provider OLE-DB non supportino l'aggiornabilità da un .ADP o la supportino
con varie limitazioni (solo cursori Client per esempio).
Con i "server collegati" ho già provato e pare che i recordsets siano a sola
lettura.
Sarei felice che tu mi smentissi, ma pare che gli .ADP (attualmente) siano
consigliabili solo con SQLServer.
> Personalmente uso le pass-through in modo massiccio su DB2/400. Devo dire
> che non sono molto contento delle prestazioni.
> Sarà colpa dell'As/400... dei driver ODBC... e altro ancora.
Non conosco DB2.
Comunque è strano quanto scrivi: l'SQL Pass Through non è viene interpretato
dal Driver ODBC.
Comunque, non dirmi che stai usando un '.ADP con IBM DB perchè non ci
crederei ;-)
> > Ed esistono procedure Client-Server della madonna _non voglio far
> > pubblicità, ma se insisti_ che lavorano anche in remoto basate su tale
> > configurazione.
> Mi baso su quello che ho vissuto sulla pelle.
Anch'io mi baso su quello che ho vissuto sulla mia pelle (che temo sia più
vecchia della tua ;-(
> > 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...
> 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.
Maggior dispendiosità?
Sono d'accordo, eccome.
Ma DAO/ODBC non è un accrocchio: è una tua, assai soggettiva, opinione.
> 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
Scusa, senza ODBC è chiaro che DAO consente solo di creare applicazioni JET.
Però non stiamo ragionanzo per assurdo ;-)
Saluti.
Simone Calligaris
"OneEDP"
> > Mi riferivo al TH "usate Access come FE" che mi pareva avessi aperto tu.
> > Forse mi sbaglio.
.
> 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.
Superficiale, ma soprattutto assai vecchia!
> 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.
OneEDP
news:7gF4b.281457$Ny5.8...@twister2.libero.it...
>
> "OneEDP"
>
> > > Mi riferivo al TH "usate Access come FE" che mi pareva avessi aperto
tu.
> > > Forse mi sbaglio.
> .
> > 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.
>
> Superficiale, ma soprattutto assai vecchia!
>
> > L'ho scoperto solo dopo.
>
> 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.
OneEDP
>
> "OneEDP"
>
> > > Transazioni in aree ODBCDirect?
> > > Non vedo nulla di strano o sconvolgente!
>
> > Dimmi sinceramente la tua opinione: te la sentiresti di affidare
> > un'operazione che coinvolge più server per completare un'unica
> trasnsazione
> > (ossia transazioni distribuite)? Come si comporta la commit/rollback sui
> > vari server? Te lo chiedo perché non ho idea come avvenga con DAO/ODBC.
>
>
> Nei software che abbiamo scritto prima dell'avvento degli .ADP (e che si
> continua a mantenere) praticamente tutti gli Update facevano ricorso a
> Transazioni.
>
> Però il discorso di transazioni distribuite mi è nuovo: ma scusa, in che
> ambito lavori, un ente pubblico con 500 Clients in rete? ;-)
>
>
I server coinvolti sono uno per filiale fino ad un massimo di tre gli
utenti fino a 50.
> > > Esistono vari modi per far lavorare il Server SQL (pass-trought,
> > ODBCDirect)
> > > restituendo solo i risultati al client.
>
> > E qui mi trovi d'accordo. Quando parlavo di DAO lo assegnavo (per
> > semplicità) al solo motore Jet su tabelle native di Access. E' su questo
> > tipo che sono sfavorevole. Io preferisco usare un ambiente il più
> possibile
> > "eterogeneo" come quello dei progetti ADP.
>
>
> Adesso mi offendi: secondo te avrei sostenuto un TH sul confronto tra Jet
e
> SQLServer?
>
No non ho fatto confusione, nè credo che qui stiamo mettendo a confronyo
l'incofrontabile.
Il paragone fatto è tra DAO e ADO. Poi sono stati coinvolti ADP e quindi
irrimediabilmente SQL Server.
Da qui è nato l'equivoco.
> Comunque non dimentichiamo che gli .ADP nascono per lavorare
esclusivamente
> con SQLServer.
> Sono una soluzione nativa senza compromessi, ma poco flessibili.
> Avrai notato, per esempio, che molti Accessisti usano MySQL come BE
> attraverso ODBC ... e con buoni risultati.
>
> Con gli .ADP si potrebbe al limite aprire recordsets ADO e assegnarli
> sistematicamente a Runtime ai vari oggetti.
> Ma a parte che la programmazione diventerebbe macchinosa, credo che molti
> provider OLE-DB non supportino l'aggiornabilità da un .ADP o la supportino
> con varie limitazioni (solo cursori Client per esempio).
> Con i "server collegati" ho già provato e pare che i recordsets siano a
sola
> lettura.
>
> Sarei felice che tu mi smentissi, ma pare che gli .ADP (attualmente) siano
> consigliabili solo con SQLServer.
>
>
> > Personalmente uso le pass-through in modo massiccio su DB2/400. Devo
dire
> > che non sono molto contento delle prestazioni.
> > Sarà colpa dell'As/400... dei driver ODBC... e altro ancora.
>
>
> Non conosco DB2.
> Comunque è strano quanto scrivi: l'SQL Pass Through non è viene
interpretato
> dal Driver ODBC.
Le SPT inviano le richieste nel linguaggio nativo usando ODBC. Questo è ciò
che faccio con DB2.
>
> Comunque, non dirmi che stai usando un '.ADP con IBM DB perchè non ci
> crederei ;-)
>
>
Nulla me lo vieterà se sarà necessario... ma a quel punto penso che userò o
DTS e/o Jet da intermediario.
> > > Ed esistono procedure Client-Server della madonna _non voglio far
> > > pubblicità, ma se insisti_ che lavorano anche in remoto basate su tale
> > > configurazione.
>
> > Mi baso su quello che ho vissuto sulla pelle.
>
>
> Anch'io mi baso su quello che ho vissuto sulla mia pelle (che temo sia più
> vecchia della tua ;-(
>
Non ti abbattere... coraggio.
I miei primi timidi "listati" risalgono da Commodore64.
> > > 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...
>
> > 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.
>
> Maggior dispendiosità?
> Sono d'accordo, eccome.
> Ma DAO/ODBC non è un accrocchio: è una tua, assai soggettiva, opinione.
> > 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
>
> Scusa, senza ODBC è chiaro che DAO consente solo di creare applicazioni
JET.
> Però non stiamo ragionanzo per assurdo ;-)
>
Bhè volevo azzardare ADO vs DAO su file .mdb per cambiare argomento.
Per curiosità. Con ODBC ognuno si è fatto le proprie opinioni in base al
costeso di lavoro.
> Saluti.
>
Simone Calligaris
"OneEDP" <
> > Scusa, senza ODBC è chiaro che DAO consente solo di creare applicazioni
> JET.
> > Però non stiamo ragionando per assurdo ;-)
> Bhè volevo azzardare ADO vs DAO su file .mdb per cambiare argomento.
> Per curiosità. Con ODBC ognuno si è fatto le proprie opinioni in base al
> 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.