Newsgroup: it.comp.appl.access
Titolo: access si può ritenere programmazione ad oggetti?

secondo voi?
che differenza c'è se non lo fosse fra questa e quella a oggetti?
grazie a tutti. 

 che differenza c'è se non lo fosse fra questa e quella a oggetti?
Per capire come venga definito un ambiente di sviluppo totalmente a oggetti
dovresti affrontare i fondamenti di Java (oppure .NET).
Tutto, ma proprio tutto quello che si fa, "prende vita" da classi.
Non esistono Sub e function slegate dal contesto, ma solo proprietà e metodi
di classi.
Non esistono on erro GOTO Err_Handler ma una classe specifica per la
gestione delle eccezioni.
All'atto pratico, specie nel settore gestionale, i vantaggi di un ambiente
puramente a oggetti rispetto ad uno misto o tradizionale sono filosofici.
Ciao.


ovvero? 

 ovvero?
Concezione diversa, risultati uguali (sulla maggior parte delle
problematiche).
Che poi a livello promozionale faccia comodo sostenere che la programmazione
Java style sia l'unica possibile per avere codice riusabile, è un altra
questione ... per gonzi.
Ciao.

 è un modello relazionale.
Beh, questo diamolo per scontato su icaa ;-))
Ciao.

 grazie a tutti.
No, VBA non è un linguaggio di programmazione orientato agli oggetti. Sono
troppe le caratteristiche che gli mancano per potersi considerare tale.
L'unica cosa che si può dire è che VBA consente l'incapsulamento
(caratteristica comune a tutti i linguaggi di programmazione orientata agli
oggetti) perchè ti puoi definire particolari moduli, detti, "moduli di
classe". Attenzione al verbo che ho usato: definire e non dichiarare. A VBA
manca, infatti, la parte dichiarativa dei moduli di classe (per questo io
non li considero vere e proprie classi) necessaria alla descrizione formale
di classi di isomorfismo, caratteristica principale della programmazione
orientata agli oggetti.
In altre parole è  l'isomorfismo il concetto chiave della programmazione
orientata agli oggetti, non l'incapsulamento.
Con i moduli di classe in VBA si 'simula'  il concetto di classe, ma è
rischioso confondere le due cose!
C++ e Java, ad esempio, sono veri e propri linguaggi dotati del formalismo
necessario alla programmazione orientata agli oggetti.
Addddisposizzzione!
--
Simplex2
www.mdenittis.it

 che differenza c'è se non lo fosse fra questa e quella a oggetti?
per quel poco che conosco di VBA, non lo si può ritenere un linguaggio Object 
Oriented, infatti non implementa nessuna di queste tre caratteritiche:
incapsulazione, ereditarietà e polimorfismo.
Forse un po' l'incapsulazione, ma molto debolmente.
Che poi in VBA si usi un modello di riferimento ad oggetti, è fuori 
discussione.
-- 
Mauro Falzari 
   [ 
http://digilander.libero.it/mauro.falzari
 ]
 
 "Se guardi nell'abisso, anche l'abisso guarda in te." 
   (Friedrich Nietzsche)

 Delphi (Object Pascal) tra i linguaggi OOP!!!
ho detto una stupidaggine: il C non c'entra un C..


 Che fra l'altro avevo letto che era ottimo per i database.
forse era riferito allo stretta connessione con la tecnologia BDE (un motore 
di database ormai obsoleto).
 
Il vantaggio dei linguaggi OO è che permettono di costruire delle gerarchie 
di "oggetti" (il termine tecnico è "classi") di qualsivoglia grandezza e 
complessità.
In Delphi per esempio, si può accedere a un database Access mediante lo 
strato ADO (Active Data Objects), o volendo anche attraverso lo strato 
inferiore DAO.
Per esempio, esiste un "componente" (altro termine tecnico che indica un 
oggetto che incapsula del codice, manipolabile nell'ambiente di sviluppo a 
design time) che si chiama TADOTable (il cui nome è intuitivo...) che 
"deriva" (cioè eredita tutte le caratteristiche e ne estende le funzionalità) 
da TCustomADODataSet, il quale deriva da TDataSet, e così via fino ad 
arrivare alla classe madre di tutte le classi che è TObject.
Naturalmente tutta questa implementazione è visibile: si può vedere nei 
sorgenti come è stato implementato ogni singolo metodo o proprietà; in 
pratica (se sai leggere i sorgenti, e ci vuole una certa dimestichezza col 
linguaggio) puoi vedere come funziona qualsiasi cosa!!!
Oltre ai sorgenti in formato testo, ci sono anche i sorgenti in formato 
compilato, quindi non leggibili (di solito, perchè l'autore vuole proteggere 
il suo prodotto), però la stragrande maggioranza del codice in circolazione 
non solo di privati ma anche di prodotti commerciali (come le griglie di 
DevExpress o gli IBObjects, tanto per dire due che mi vengono in mente) è 
aperta.
Anche la VCL, cioè la libreria base dell'IDE, cioè dell'ambiente di sviluppo 
integrato di Delphi, è tutta open source! Stessa cosa per quasi tutte le 
librerie fornite a corredo di Delphi (mi pare la Jpeg no, ma per motivi di 
copyright).
Capisci che solo questo fatto, di per sè, è già molto istruttivo.
Mi sono fatto prendere la mano da Delphi e dall'open source, ma credo che ne 
valga la pena!


 discorso...
sarebbe interessante capire perchè queste caratteristiche vengano sfruttate 
così poco


 così poco
Se ti riferisci a Sergio, credimi è meglio!
Del resto anche la compagna ha convenuto che è possibile "sfruttarlo" poco:
per quello che ne tira fuori...
MAssimiliano
p.s. oh ragà, Antonio non c'è più e io devo sfottere qualcuno!!!

 Delphi (Object Pascal) tra i linguaggi OOP!!!
Che fra l'altro avevo letto che era ottimo per i database.
SunRex


 SunRex
Mi sono accorto dell'errore solo ora che me lo hai fatto ossservare.
ERRATA CORRIGE:
sotituire a Isomorfismo, POLIMORFISMO.
Questo è un buon articolo molto sintetico:


 richiede (se non eccezionalmente) approcci veramente a oggetti.
troppa facilità nel creare rapidamente applicazioni (mi riferisco appunto al 
significato del termine RAD), può creare false illusioni: una cosa che mi ha 
sconvolto di Visual Basic in generale (visto che stavamo parlando del 
linguaggio di programmazione di Access) è l'uso sterminato dei Variant. 
Quando manipolate una variabile, spesso non sapete esattamente di che tipo è. 
Quando eseguite del codice quasi sempre non saprete mai veramente se quella 
data routine funzionerà o no finchè non verrà eseguita (mi riferisco al 
linguaggio semicompilato).
Non c'è un controllo robusto sugli errori. Mi pare che esista qualcosa come 
un On Error Resume Next ...
Per gestire bene gli errori dovreste mettere degli On Error Goto in ogni 
routine.
Cambiando qualcosa da qualche parte (riporto esperienze di programmatori VB 
di mia conoscenza) in un programma complesso, succede che non funziona più 
nulla o appaiono errori inspiegabili e si perde molto tempo a cercare di 
capire da cosa è causato l'errore.
Il codice è poco riutilizzabile. Non ho ancora capito dove stia 
l'ereditarietà in VB ma ripeto che lo conosco poco. Non mi pare che sia molto 
incoraggiata la modularità del codice (se non sbaglio si possono esportare 
moduli come file di testo BAS, ma tutto finisce lì). 
Non potete vedere come sono implementate neppure le più semplici funzioni di 
sistema come Date.


 Forse un po' l'incapsulazione, ma molto debolmente.
Attenzione: le cose non stanno così (e oltretutto si sta facendo
confusione).
Anzitutto non esiste "VBA": la versione 6.XX del linguaggio Office Visual
Basic è in tutto e per tutto corrispondente al linguaggio Visual Basic 6.0.
Cambia naturalmente il modello a oggetti dell'ambiente Host ma non il
linguaggio in sè.
Detto questo, è corretto definire Visual Basic 6.XX un linguaggio "misto".
L'architettura è lontana dalla concezione basata su Classi di .NET, però
supporta incapsulamento, ereditarietà e polimorfismo.
Anche solo sfogliando la documentazione acclusa alle versioni DEV di Access
2000 o XP si trovano esempi concreti di:
. creazione d'eventi personalizzati con withevents
. Implementazioni di classi e interfacce astratte
. polimorfismo attraverso interfacce astratte
. pianificazione e progettazione di modelli a oggetti
Che poi queste caratteristiche vengano sfruttate di rado, è un altro
discorso...
Comunque finito questo periodaccio preparerò qualche esempio per il Sito
Comune.
Saluti.

 Saluti.
Altro esempio di Polimorfismo di Access:
Sergio MAZZA.
Appare un bravo sviluppatore Access, in realtà è Virus potentissimo che
fracassa tutti gli Hd
di chiunque parli di lui!!!
Millenium bug gli fa un baffo!
Ora sei convinto che Access accetta i polimorfi???
MAssimiliano

 così poco
La stessa domanda potresti farla su iclvb.
Comunque:
1) Chi non ha cominciato (già dalla scuola) in C++ si trova a disagio con
l'approccio a oggetti
2) La documentazione standard di Access e/o Visual Basic approfondiscono
poco questi argomenti (e tanti altri non meno interessanti per la verità).
3) Sviluppare gestionali con ambienti estremamente RAD come Access, non
richiede (se non eccezionalmente) approcci veramente a oggetti.
Un tempo era diverso: pensa a chi ha sviluppato l'interfaccia
"quasi-visuale" del famoso PassPartout in C++: non credi che abbiano tratto
grandi vantaggi dall'approccio a oggetti?
Ma con un ambiente che ti svincolo totalmente dalle problematiche di
creazione dell'interfaccia, delle barre dei menù, della reportistica
avanzata...
Saluti.

 necessario alla programmazione orientata agli oggetti.
scusate io sono un programmatore Delphi e ho letto per caso la 
discussione...oltre a C#, C++, C e Java, vi siete dimenticati di citare 
Delphi (Object Pascal) tra i linguaggi OOP!!!
-- 




 come la pensavate.
Saluti: Simone

 sistema come Date.
Vero, ma questa è una caratteristica strutturale di (quasi) tutti gli
ambienti "RAD",
Delphi è stata la prima sorprendente eccezione.
Il successo di prodotti come PowerBuilder, Access, Omnis studio e simili
è decretato da un set di strumenti per gestire DB estremamente potenti,
flessibili, agili e orientati
all'obiettivo.
Per contro si deve rinunciare ad avere il "controllo totale" della
situazione ... la qual cosa all'atto pratico non comporta problemi o
limitazioni (specie se è possibile sfruttare l'API del sistema operativo).
Chiaramente nel contesto di questa discussione: software gestionale.
Saluti.

 all'obiettivo.
ehm...questa mi era sfuggita a una prima lettura ma sono costretto a 
dissentire (pur cosciente che sono "in casa d'altri" e potrei scatenare una 
polemica), per la parte che riguarda quel poco che conosco di Access (gli 
altri prodotti che hai citato non li conosco).
Concordo col fatto che Access sia un prodotto estremamente flessibile, RAD e 
piuttosto ergonomico, però non lo definirei un vero RDBMS.
Da quel che ho potuto superficialmente vedere di Access, ti/vi pongo queste 
domande:
1) come si crea un trigger in Access?
2) e una stored procedure?
3) per modificare il valore di partenza o resettare il valore di un campo 
autoincrementante (per qualsivoglia motivo ciò possa servire, per esempio 
farlo ripartire da 0 o da 10.000.000) come fate?
4) in una relazione master-detail, come avviene il controllo sulla 
consistenza tra foreign key e primary key: automaticamente a livello di 
database o dovete scriverlo da codice? 
5) se qualcuno (qualche applicazione) accede al vostro database MDB non 
attraverso Access, ma poniamo via ADO e modifica direttamente i dati, 
bypassando così tutti gli eventi che avete scritto sui vari Recordset, che 
succede?
6) che controllo avete sulle transazioni?
7) come si crea un dominio?
8) quando usate un campo di tipo stringa, potete dichiararlo di lunghezza, 
poniamo, 10.000 o siete costretti a usare un altro tipo di campo? 
9) potete eseguire script sul database?
10) potete accedere al database via TCP/IP?
11) quando più utenti stanno lavorando sulla stessa tabella e un'utente 
modifica una riga, gli altri vedono le modifiche in tempo reale?
Queste tanto per dire le prime che mi venivano in mente.
E non vi sorprende sapere che Firebird 
 
http://firebird.sourceforge.net
 
http://www.ibphoenix.com
-un database completamente freeware, open source, derivato dallo storico 
Interbase- tutto questo (e molto di più) ce l'ha?
E che con un tool totalmente freeware come IBExpert Personal Edition 
(
www.ibexpert.com
) si riesce ad amministrare in modo completo e visuale il 
database?
Tutto questo a costi zero.
(una piccola chicca: la versione embedded di Firebird, cioè la DLL che è il 
motore del database e permette di far girare applicazioni in locale senza 
installare il database server sulla macchina, occupa lo spazio di un floppy!)
Non voglio togliere nulla alla facilità d'uso di Access, però ho come 
l'impressione che per applicazioni abbastanza "serie" scricchioli un po', o 
perlomeno vi costringa a parecchie acrobazie.


 Comune.
Premessa,
sviluppo in VBA da tre anni per l'Ufficio in cui lavoro ma  l' UFFICIO non
mi ha fornito la versione DEV di Office!
L'UFFICIO, però, mi ha procurato due bei CD ROM intitolati Visual Studio 6 -
MSDN Library.
Illuminato e stupito dalle tue affermazioni sulle 'potenzialità' OOP offerte
da VBA, ovvero VB, mi sono prodigato nella ricerca
di articoli sul polimorfismo su 'Visual Studio 6 MSDN Lib.' ed ho trovato
alcuni articoli interessanti e, credo, i citati esempi concreti.
Visto che l'oggetto del thread è interessante, propongo a tutti la lettura
degli articoli che ho trovato: Un buon punto di partenza è il seguente URL
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vbcon98/htm
l/vbconinheritancepolymorphismallthat.asp
Anche 'solo sfogliando' le suddette pagine che, per una successiva più
attenta lettura mi sono stampato, ho avuto l'impressione che il polimorfismo
di VB
sia un po 'tirato per le orecchie'. Mi riservo di studiare meglio gli esempi
proposti dagli articoli, tuttavia, alla luce dello 'sfoglio' della suddetta
documentazione, mi pare di capire che il polimorfismo di VB è perneato sul
concetto di interfaccia.
L'ereditarietà non è vista come estensione di una classe base ma solo come
implementazione di una interfaccia, che in VB corrisponde forzatamente al
concetto di classe atratta. Attenzione: nei linguaggi strongly typed OOP le
classi astratte non sono istanziabili mentre in VB lo sono! Cito
testualmente: <<Note   Properly speaking, an abstract class is one from
which you can't create objects. You can always create objects from Visual
Basic classes, even if they contain no code; thus they are not truly
abstract.>>.
Dunque, c'è nell'argomento 'polimorfismo in VB' un po di confusione e si
comprende (e si vede) benissimo che VB non è stato originariamente pensato
per supportare la programazione OOP e che successivemente, per tendenze di
mercato, la MS gli ha aggiunto, direi forzatamente, costrutti per
l'ereditarietà.
Per ora rimango della mia opinione (già espressa in questo Thread): VB non è
propriamente un  linguaggio OOP.
Saluti.
--
Simplex2
www.mdenittis.it


Su una cosa hai ragione: conosci poco Access e ti dico che confondi
la gestione del Front End con quella del BackEnd.
MAssimiliano


P.S. non vi sorprendete se non vi rispondo fino a metà della prossima 
settimana, ma sono in partenza.


 definito di dove finisca il database e dove inizi l'interfaccia utente.
Questo è vero, ma io lo interpreto come ricchezza.
Access è base dati, è sviluppo Interfacce, è sviluppo Report
e può essere supportato o da Jet o Sql-MSDE in maniera diretta o ODBC.
Ma chi ti dà tutte queste opportunità?
Last but not least, questo Ng e quello Microsoft, i vari siti con codice
aperto, molto efficaci
MAssimiliano

 wrote in message
news:jlVrd.1261$
Zk.3...@twister2.libero.it

He...He...!!
Io ritengo che Mauro abbia ragione da vendere, ma non nello specifico
tuo Simone, in generale....!
Spesso vengono postati spezzoni di codice nel quale si ha dichiarazioni
di variabili ma non esplicita, di conseguenza variant.
Questa è una deformazione tipica di chi non ha cultura informatica
e che ha iniziato a smanettare con Access in quanto comodo strumento
per generare applicativi in modo più agevole che con altri linguaggi.
Chi ha iniziato con linguaggi più a basso livello è stato costretto
ad imparare la dichiarazione e soprattutto la liberazione di memoria.
Non parliamo di chi usava l'Assembler che se non liberava Stack e
registri aveva ben poco da fare, anche perchè una volta l'assembler
ti imponeva di dichiarare l'area di Memoria da dedicare alle variabili
per non parlare poi di quando i dinosauri programmavano Z80 e 6502
nei quali occorreva tener conto della mappatura di memoria del
processore per gestire Grafica Tastiera, Interrupt(ora deviato
dal SubClassing) ecc......!!!
Sono prodotti diversi con limiti diversi e destinatari diversi,
tuttoquesto
per soddisfare esigenze disparate ecc....!!!
Con questo non che access sia uno strumento per smanettoni, ma è uno
strumento che offre anche a chi ha poca esperienza la possibilità
di ottenere qualche risultato, ovvio che la mancanza di una scolarità
porta ai difetti di programmazione di cui parlate.
Il fatto che chi usa Access spesso non è portato ad approfondire
tematiche di programmazione a basso livello potrebbe derivare
dal fatto che non sempre serve, oltre che spesso è complesso e richiede
preparazioni decisamente più specializzate.(questo non significa che non
si faccia)
Saluti
-- 
Posted via Mailgate.ORG Server - 
http://www.Mailgate.ORG

 Chiaramente nel contesto di questa discussione: software gestionale.
nè è mia intenzione scatenare una guerra di religione, volevo solo sentire 
come la pensavate.
-- 


 la gestione del Front End con quella del BackEnd.
sicuro che invece questa non sia una confusione a cui porta Access? 
Intendo mischiare la gestione dei dati vera e propria (il database insomma) 
con la gestione dell'interfaccia utente. Mi pare (ma confesso che è 
un'impressione molto superficiale, la mia) che non ci sia un confine ben 
definito di dove finisca il database e dove inizi l'interfaccia utente.
-- 


 dal SubClassing) ecc......!!!
Alessandro ma da quanti anni è che programmi?
Sunrex
[CUT]



Con linguaggi ad alto livello lo faccio dal 97 solo per Hobby.
Ho programmato per 6 anni Assembler
un pò per passione un pò per un progetto scolastico, ed un paio d'anni
per un'azienda su processori di automazione industriale quando gli Z80 erano
il
gioiello della tecnica...! per l'appunto l'era dei dinosauri...!
Per capirci mi divertivo a smanettare con C64 e VIC20, ai tempi c'era
una Rivista che si chiamava CommodoreComputer era l'equivalente
del NG ora, allora i miei giochini li inviavo alla rivista, ora c'è il WEB.
Ciao
-- 
@Alex (Alessandro Baraldi)
---------------------------------------------------------------------------
http://www.sitocomune.com/
http://www.mantuanet.it/alessandro.baraldi/
---------------------------------------------------------------------------

 ha scritto nel messaggio
news:Xns95B47BB64E82645...@130.133.1.4...

Riguardo a questa ultima osservazione c'è da fare un distinguo.
Infatti la confusione a cui ti riferisci può accadere solo a chi usa Access
senza usare VBA.Il confine c'è ma dipende dalle qualità dello sviluppatore
Tutte le tue osservazioni vengono bene o male  svolte da Access nel senso
che non è access ma VBA dietro che glielo permette.Ha ragione Ma una cosa è
il Beck End
ed una il Front End.
L'unico limite di Access non è nel linguaggio usato per programmarlo
,secondo me,
ma nella quantità di dati che puoi gestire (2 giga con A00) e nel numero di
utenti
collegati contemporaneamente.
SunRex


 [CUT]
Si narra che Dio un tempo chiamò Noè e Alessandro e disse loro:
a te ti faccio capitano di una nave,
a te mi serve un programma che faccia acqua da tutte le parti!!!!
;-P
MAssimiliano

 Saluti.
Purtroppo ci sono...!! ;-)
Quì andiamo su un campo delicato e la cui valutazione
è spesso più personale che obiettiva.
Quello che c'è pubblicato sul SC è di VARIO livello e non ritengo
possa essere preso come esempio ci sono ottimi lavori e ci sono
lavori discutibili sotto il profilo tecnico di sviluppo, ma non è questo
il punto.
Intendo dire che Access è un bellissimo strumento fruibile anche da chi
non ha basi di programmazione, cosa meno facile che con C++ o Delphi
pertanto gli errori più diffusi della gete poco esperta che usa Access sono
tipici di
chi non ha avuto educazione informatica.
Non troverai facilemnte gente che programma in C++ che non dichiara
variabili... non può, ma sicuramente chi si è avvicinato a C++ no lo ha
fatto
per farsi il Database d'ufficio, per quello la gente si avvicina ad Access
si dice
USER_FRIENDLY (credo)
Ripeto però che non intendo denigrare Access, anzi, lo ritengo talmente un
bello strumento che chiunque lo può usare a livelli +/- approfonditi con i
propri
limiti.


 per generare applicativi in modo più agevole che con altri linguaggi.
Scusa Alessandro: sul sito comune sono pubblicati decine di lavori (di vari


 domande:
(cut)
Cercherò di rispondere analiticamente alle domande, legate però
a una scarsa conoscenza del prodotto.
E non lo dico polemicamente: è un dato di fatto, da quanto scrivi.
Importante: non è questione di giocare in "casa o fuori casa" ma
semplicemente prendere atto della realtà per quella che è   :-)
Premessa:
ACCESS ----  è un ambiente Front- End interfacciabile a QUALUNQUE  motore di
Database (e lo sottolineo)
JET ------        motore default installato con Access, file-Sharing
MSDE -------- motore per applicazioni Client-Server (versione lite di SQL
Server)
MySQL   ----   (altri motori spesso utilizzati con Access)
FireBird------
IBM DB2/AS400
... etc.
Access è anzitutto un ambiente di sviluppo Front-End, con caratteristiche
tipicamente RAD, ma dotato di un linguaggio di programmazione molto più
flessibile rispetto ai sistemi di scripting che generalmente includono
prodotti di analoga natura (alcuni esempi li ho già fatti nel Th).
Parlando di flessibilità mi riferisco in particolare agli interfacciamenti
possibili con l'API del sistema operativo.
Visitando 
www.sitocomune.com
  o 
http://www.mantuanet.it/alessandro.baraldi/
puoi trovare molti esempi pratici di funzionalità che in altri prodotti RAD
possono essere ottenute solo con Plug-Ins (diciamo ActiveX, .DLL e simili).
Purtroppo l'ambiente in oggetto non è un editor di codice C++ o Pascal,
quindi la distribuzione delle applicazioni è basata su un Runtime royaltee
Free incluso nei pacchetti DEV del prodotto.
Anche in questo caso niente di nuovo o diverso rispetto a tanti classici
prodotti RAD.
Per la cronaca, i files (meta) Compilati delle applicazioni Access hanno
estensione .MDE oppure .ADE.
Il motore di database predefinito di Access è Microsoft JET: una engine
File-Sharing con caratteristiche interessanti per la sua fascia, ma con
tutte le limitazioni del caso.
Le tue osservazioni, peraltro interessanti, sono riferite proprio al motore
JET e in buona parte corrette.
All'atto pratico:      JET sta ad Access come Paradox sta a Delphi
Da parecchi anni, Microsoft raccomanda d'utilizzare MSDE invece che JET per
applicazioni multiutenti.
Le versioni "Developer" di Access contengono le licenze di distribuzione
Royaltee Free del suddetto MSDE.
A tal proposito ACCESS ha due anime:
1)  L'editor di applicazioni per MS JET  (e ODBC)
2)  L'editor di applicazioni .ADP:  ovvero puri files di progetto agganciati
attraverso ADO/OLE-DB a MS SQLServer.
I cosiddetti files di progetto .ADP lavorano nativamente ed esclusivamente
con SQL Server/MSDE pur mantenendo gli strumenti "classici" di Design per
Forms e Reports (con alcune inevitabili differenze operative).
Usando l'editor .ADP, il vecchio motore JET non viene caricato in memoria:
non esiste più.
Con questa configurazione, di conseguenza, non esiste alcuna delle
limitazioni che suggerivi con le tue (interessanti) domande.
All'atto pratico:    MSDE sta ad ACCESS/ADP come FireBird sta a Delphi.
(Per avere informazioni sulle caratteristiche di MS SQL Server, e un
confronto con FireBird, utilizza la KB MS o il sito dedicato al prodotto).
Vale la pena a questo punto approfondire il punto 1) in rapporto ad ODBC.
Oltre alle configurazioni ACCESS + JET  e  ACCESS .ADP + MSDE/SQL Server è
molto diffuso anche l'interfacciamento  ACCESS +  JET + ODBC +  (ODBCDirect)
+ <Altro Server di database>.
Per <Altro Server di database> s'intende in particolar modo MySQL Server
(frequente) ma anche InterBase, AS/400, Oracle e altri.
Personalmente utilizzo da anni, per tutti i nuovi progetti, la
configurazione: ACCESS + JET + ODBC/ODBCDirect + MSDE.
In questi casi la connettività col Server è meno "nativa" rispetto a quella
dei succitati .ADP: il mapping dei tipi di dati sul Client viene effettuato
dalla JET Engine.
E' una soluzione che produce buone applicazioni Client-Server, trovando la
giusta misura tra SQL lato "client" e codice SQL eseguito direttamente sul
Server attraverso ODBCDirect o Query Pass Th.
Anche in questi casi, ovviamente, l'archiviazione è delegata a solidi motori
di DataBase Server transazionali.
Chiaramente ogni motore di database ha caratteristiche e limitazioni
specifiche: SQL Server praticamente nessuna, MySQL parecchie (no triggers,
SP).
Da notare che con ODBCDirect è piuttosto semplice eseguire Stored Procedures
sul Server con parametri D'input/Output ... qualora il motore Server le
supporti.
Ecco, questo è un quadro realistico della situazione: spero d'esser stato
chiaro oltre che prolisso...
Saluti.

 propriamente un  linguaggio OOP.
Altri hanno espresso opinioni più realistiche: parlando di linguaggio con
caratteristiche "miste".
In questo caso sei troppo rigidamente legato alle definizioni studentesche
di OOP, e non lo dico con intenzioni polemiche.
Comunque, dopo le vacanze, vedrò di realizzare una versione "Lite" per il
S.C. di un lavoro sviluppato negli ultimi anni (un wizard dei trattamenti
per maschere e Reports) in cui ho fatto ricorso alle tecniche oggetto del
Th.
Ne riparleremo...
Saluti.

 grazie a tutti.
weee ragazzi che mega news che ho aperto un dibattito all'ultimo sangue.... 
ma chi sono?



Mi permetto di entrare in questa discussione perchè conosco Access e
conosco database più complessi come SQL Server o Oracle.
Il fatto fondamentale è questo:
Access ingloba in un unico ambiente un database e una serie di tools
per lo sviluppo dell'interfaccia. Quindi posso strutturare tabelle e
query per organizzare i dati ed interrogarli, posso creare al volo una
query di qualsiasi tipo e lanciarla quando mi pare e quando mi serve.
Tutto questo in un unico ambiente (come già detto). Posso programmare
delle maschere di input che, ad esempio, per un certo campo non mi
consentono di inserire dei numeri (nell'esempio sarebbe una maschera
che contiene un campo di inserimento associato ad un campo testo di
una tabella). Dalla mia maschera non potrò mai inserire dei numeri in
un campo di testo dato che dietro del codice VBA sovraintende a questa
operazione... ma Mauro Falzari ha formulato una domanda provocatoria,
concreta e sinceramente reale, perchè se un'altra applicazione esterna
al database stesso, tipo un eseguibile sviluppato in Visual Basic o
qualsivoglia linguaggio capace di utilizzare ADO potrebbe collegarsi
al DB, cambiare i dati e bypassare quella "sicurezza" fornita dalla
maschera con codice VBA. Questo con un db access non si può evitare!
Tranne di protezioni artificiose.
Un db tipo sql server, oracle o a quanto pare anche Firebird non
consentirebbe nulla di tutto ciò semplicemente perchè il motore del db
è l'unico componente in grado di interagine direttamente con i
database e tutte le operazioni provenienti da qualsiasi applicazione
devono transitare dal motore che gestisce il db.
Una volta fissata una regola per una tabella, vale per tutti i
processi che accedono al db, nessuno escluso.
Per tutte le altre domande provocatorie di Mauro, devo dar ragione a
lui... di fatto Access non è un database nel senso ampio del termine,
è solo una parvenza di database (non per offendere access, per carità
io personalmente lo uso in lungo e in largo...).
Non vi è nulla che assomigli ai trigger o alle stored procedure, fermo
restando che per realizzare tali meccanismi devi ricorrere alla
fantasia creando accrocchi ed improvvisazioni (magari anche
funzionanti bene).
Se poi si vuole accedere al db via TCP/IP allora ti dico che non è
possibile, o meglio in giro e sul panorama access per questo
problemino è comparso un certo RDO (Remote Data Object) che è un
equivalente di ADO e DAO capace di gestire database remoti via rete,
ma non propriamente access...
Per i campi a notevole lunghezza (10.000 caratteri) esiste il campo
MEMO capace di contenere fino ad un massimo di 64Kb di dati.
Se devi assegnare dinamicamente la lunghezza di un campo, questo non è
possibile.
Il limite di access non si vede solo sulla capacità totale di dati
gestibili (2 GB), ma anche sui singoli dettagli tipo non è possibile
definire una tabella con più di 256 campi (sarebbero tanti per
qualcuno ma pochi per qualcun'altro). I singoli record non possono
superare una specifica quantità di dati (ora non ricordo quanto...)
I limiti di access sarebbero ancora molti rispetto ai db seri, ma il
fatto è che chi usa access lo fa perchè è un sistema rapido per lo
sviluppo di database ed applicazioni in un unico momento, senza
grossissime pretese.
Chi si orienta ai database seri lo fà perchè deve sviluppare una
applicazioni con una solidità ed affidabilità intrinseca,
l'interfaccia e l'interattività viene dopo...
La verità stà nel mezzo... ben vangano tutte le critiche ma di fatto è
che i due prodotti sono diversi e non direttamente paragonabili.
Paragonabili sarebbero SQL Server ed Oracle, Access e forse il vecchio
DBIII.
Che ne dite?
ciao!


Mauro ha detto delle verità come le hai esposte anche te.
Posso però dire che quando si parla di Access non si deve
SEMPRE e PERFORZA parlare di JET(motore o parvenza di Database).
ACCESS è un'interfaccia utente per quanto mi riguarda decisamente
più solida e stabile di VB per il quale occorre CristalReport
per gestire Stampe, occorrono OCX di ogni marca e modello per gestire
dati ecc...!
Access(Client) offre controlli NATIVI molto solidi e performanti, senza
contare
che passando a Progetti di tipo ADP non si passa nemmeno per JET, ma si usa
direttamente OLEDB e ADO.
Questo solo per precisare che spesso sono persone che sviluppano in
linguaggi
paralleli a vedere lo STEREOTIPO di ACCESS.
Lo sanno anche le pietre che JET è un motore limitatissimo usiamo ACCESS
come
CLIENT verso SQL_SERVER via ADP che prevede in modo NATIVO e VISUALE la
strutturazione di Oggetti SP/VISTE TRIGGER(visuali che sono Relazioni)
ecc...!
Ciao


 Ne riparleremo...
Non ne dubito.
Saluti a tutti e buone feste.
--
Simplex2
www.mdenittis.it

> Che ne dite?
(cut)
Leggi la risposta che ho dato nel Th un pò più sotto.
ACCESS e JET sono cose differenti: in questo TH non si stava assolutamente
parlando delle limitazioni del vecchio motore JET.
Saluti.

 di cucina).
La concettualizzazione informatica non è matematica.
Esistono DB relazionali, altri che non lo sono, altri ancora che hanno
caratteristiche "miste" (ti piaccia o no la definizione).
Un discorso analogo si può fare in rapporto al presente Th.
Chiudo: saluti



E chi ha parlato mai di JET?
qui si è parlato di ACCESS in generale e non di JET in assoluto.
Il mio contributo al discorso di Mauro era solo una puntualizzazione
visto che alle sue domande (per altro forse poco capite) si è dato
risposte non attinenti... tutto qua.
Tutti sanno che JET è nato in partenza limitato, ma lo scopo di JET
come quello di ACCESS non è fornire gli strumenti per un database nel
vero senso della parola. Serve solo per soddisfare esigenze immediate
come la realizzazione di un archivio personale o cose del genere ma
non venitemi a dire che affidereste ad ACCESS la gestione di una
quantità impressionante di dati e magari anche "sensibili".
tutto qua.
ciao.
x Simone, non ho trovato il tuo th... se lo avessi allegato alla
risposta probabilmente ti avrei potuto anche dare ragione...
ciao!

 anche gli zoologi).
Ribadisco un concetto di per sè elementare: nel nostro settore le cose
affrontate concretamente hanno una valenza diversa rispetto alle relative
definizioni studentesche o accademiche.
E' inutile trincerarsi dietro un: "se <Pinco> non rispetta tutte le seguenti
caratteristiche significa che NON è <pallino>".
In ambito informatico le implementazioni di determinate tecnologie o modelli
(dal Database relazionale alle tecniche OOP) scritti sulla carta da qualche
entusiasta pioniere ... sono sempre state tutt'altro che immutabili e
rigorose.
Ai tempi dell'università dopo aver sviluppato la tesi in ambiente SmallTalk,
ero tentato di sostenere che i linguaggi C++, in confronto, implementassero
rozzamente i paradigmi dell'OOP.
Ma se avessi ceduto alla tentazione di dire o scrivere cose del genere
(sebbene non prive di fondamento) mi sarei comportato da ... studente con le
dita nel naso.
Saluti.

 La concettualizzazione informatica non è matematica.
ALT.
Quest'affermazione merita una riflessione quasi da mossa scacchistica. Io
non ho citato i numeri ma i polinomi (pensa che all'inizio del Th. mi sono
confuso tra polimorfismo ed isomorfismo). Dunque, la materia con cui io ho
ritengo possibile
un confronto con la concettualizzazione informatica è l'algebra.
L'algebra è un formalismo,  cioè un linguaggio. Si parla spesso, infatti, di
linguaggio algebrico.
All'epoca in cui studiavo algebra mi ci è voluto del tempo tempo per
dissociare
l'algebra dai numeri e considerarla per quello che è: un formalismo
descrittivo che lavora a livello astratto.
La concettualizzazione è quel processo con cui descrivi la realtà adottando
dei modelli formali. Ovvio che nessun informatico adotterebbe i polinomi e
l'algebra per la concettualizzazione, però hai altri strumenti
formali con un potere ugualmente espressivo.
Nella fase di concettualizzazione devi necessariamente applicare il processo
di astrazione e quindi ti occorre un linguaggio per descrivere le tue
astrazioni. Il modello di concettualizzazione per "Tipo Astratto", usato per
la programmazione OOP, ed il modello Entità
Relazione, largamente usato nelle basi di dati, ne sono degli esempi.
Nei linguaggi di programmazione OOP, come C++ ed il Java, il costrutto
corrispondente al concetto di "Tipo Astratto" è la classe, tant'è che uno
dei più diffusi modelli  formali usati per la concettualizzazione di un
programma OOP è il diagramma delle classi (Class Diagram); Con il diagramma
delle classi descrivi formalmente la realtà dove l'applicazione dovrà agire,
ovvero descrivi con COSA l'applicazione dovrà lavorare (la cosiddetta realtà
di interesse) e con il linguaggio di programmazione OOP trasformi quel
diagramma in qualcosa che possa essere facilmente (si fa per dire) tradotto
in codice.
Da questo punto di vista "studentesco", se un linguaggio ha la necessaria
espressività formale per consentirmi di tradurre le mie astrazioni con del
codice in modo biunivoco, allora lo ritengo OOP, altrimenti è NON OOP (nella
quale categoria, complementare della precedente, ricomprendo gli ibridi, o
misti, come VBA).
Ovviamente è il mio punto di vista.
Passo:
Ciao.
--
Simplex2
www.mdenittis.it

 risposta probabilmente ti avrei potuto anche dare ragione...
Aver ragione?  Mah!
Saluti.


Giustissime tutte le tue osservazioni ma rimane il fatto che nella sua
fascia
Access è un piccolo gioiellino.Nessuno si sognerebbe di gestire un DB con
dati "sensibili" con Access.....o no?....:(
RDO è nato dopo DAO ma non ha avuto una gran vita soppiantato dopo
da ADO che puoi usare con Access.
SunRex

 cristo!
... e qualunque motore d'archiviazione.
Il link che non trovi (la risposta a Falzari) è il seguente:
http://www.newsland.it/nr/browse/it.comp.appl.access/115403.html
Ti prego di verificare razionalmente quanto scritto,  prima di proseguire
nel Th con affermazioni fuori dalla realtà.
Saluti.

 Giustissime tutte le tue osservazioni
Scusa la pedanteria: sono affermazioni giustissime, solo nel caso si lavori
col vecchio motore JET di Access.
Chi (e sono molti) sviluppa soluzioni usando MSDE o SQL Server sul lato BE,
non ha nessuno di quei limiti o problemi.
L'epoca di Access 1.1 credo sia finita da un bel pezzo: o no?
Saluti.

 ha scritto nel messaggio
news:Rb%sd.7032$Zk.1...@twister2.libero.it...

Si mi trovi daccordo.
SunRex


 caratteristiche significa che NON è <pallino>".
Stai mentendo a te stesso. Una cosa è o appartiene ad un dato insieme se e
solo se rispetta certi requisiti, altrimenti non è o non appartiene a
quell'insieme.
Questo lo sai benissimo. Il fatto che un linguaggio rispetti o meno un dato
modello fa si che esso sia o non sia coerente con quel modello.
Il fatto che esistano soluzioni ibride nei linguaggi, per convenienza
applicativa, non implica un improprio allargamento del criterio di
classificazione ovvero una defiscalizzazione delle regole (meglio dire
specifiche) con le quale giudichi un linguaggio aderente ad un certo modello
o meno.
Questo principio, sacrosanto sia in teoria, lo è anche in pratica, per lo
meno nelle cose che io affronto concretamente quotidianamente.
Co ciò non voglio sostenere che una cosa se non è bianca è nera. Io esprimo
il concetto che se una cosa non è bianca è NON BIANCA (quindi rossa,
marrone, gialla, verde, nera,.......).
Siccome ritengo di aver annoiato la maggior parte dei lettori (questo th lo
stiamo praticamente conducendo io e te a botta e risposta), ritengo sia
doveroso e riguardoso concluderlo qui.
Comunque mi dispiace liquidare l'argomento perchè è interessante. Se vuoi
continuare lo scambio di vedute (di cose da dire ce ne sarebbero) possiamo
farlo via mail. Il mio indirizzo lo trovi sul sito il cui URL è apposto alla
mia firma.
Saluti.



hai ragione... non volevo urtale la sensibilità di nessuno le mie
erano solo constatazioni... 
ciao.

 stato chiaro oltre che prolisso...
no, anzi, ti ringrazio per la dovizia di particolari nelle spiegazioni e 
ringrazio anche gli altri partecipanti a questo thread per il contributo 
apportato.


 apportato.
Saluti.