Utilizzo VB6 e in un form ( ricercadati ) con due controlli data e una DBgrid devo ricercare un record da un dtabase creato con acces. Utilizzo una routine che avevo preparato con VB5 e che funzionava mentre adesso mi da errore.

  Dim MyWorkspace As Workspace, DB As Database
  Dim Tabella As Recordset

( A questo punto carico il database GAS, che ha una tabella gas, e una  maschera di input chiede di inserire il nome da ricercare quindi )

 ricercadati.datPrimaryRS.DatabaseName = MyFile ( MyFile è il database )
 ricercadati.Data1.DatabaseName = MyFile

 Set MyWorkspace = Workspaces(0)
 Set DB = MyWorkspace.OpenDatabase(MyFile)
  Set Tabella = DB.OpenRecordset("gas") ' Apre la tabella.

"""" Qua mi genera un errore n° 13 TIPO NON CORRISPONDENTE""""""
 ricercadati.Data1.RecordSource = ("SELECT * FROM gas WHERE Nome Like '* " &
 MYVALUE1 & " *';") ricercadati.Data1.Refresh
 If ricercadati.Data1.Recordset.RecordCount >= 1 Then
 Else
 MsgBox ("NESSUN CLIENTE CON IL NOME RICERCATO")
 GoTo esci
 End If

 Tabella.Close                                   ' Chiude la tabella.
 DB.Close
 ricercadati.Data1.Recordset.MoveLast
 esci:

Spero di essere stato chiaro e un grazie a tutta la ML.

Risposta.
Probabilmente il motivo è questo: Nel progetto alla sezione riferimenti controlla se è referenziata la
libreria ado (Microsoft data access objects) se è così non basta dichiarare la variabile "as recordset" perchè l'oggetto recordset esiste anche in ado, ma bisogna  specificare anche la libreria Es: Dim rs as DAO.Recordset, oppure eliminare i riferimenti alla libreria ADO.

D: Allora, mi trovo davanti ad una list1 con tutti i nomi e a destra una TabbedDialog con il resto dei dati, ora vorrei fare così:
in base al nome selezionato (seltext) della list1 deve riempirsi la TabbedDialog con il resto dei dati (usando un DataBase MDB) omettendo il controllo Data1.

R: in DAO, fai cosi`:

dim db as database, tb as recordset, sql as string
sql = "SELECT nometabella.campo1, nometabella.campo2, eccetera"
sql = sql + " FROM nometabella WHERE nometabella.campoNome = '"
sql = sql + list1.seltext + "';"
' attento agli apici

set db = dbengine(0).opendatabase("percorso\nomedb.mdb")
set tb = db.openrecordset(sql)
tb.movefirst
do while not tb.eof
    leggi un record dopo l'altro e ne scrivi i dati sulla tabbed dialog
    tb.movenext
loop
tb.close
db.close
set tb=nothing
set db=nothing
 
 
 

D:  Sapete a cosa servono e come si usano il DataField e il DataSource,  per esempio  Text1.DataField e Text1.DataSource?
 
R: Servono a collegare l'oggetto Text Ad un oggetto Data per recuperare i campi di un recordset.

R: Queste proprieta' vengono usate dai controlli data-aware, che possono cio' interfacciarsi a tabelle di database. Con la proprieta' .datasource indichi un controllo data, a cui devi aver preventivamente settato un db ed un recordsource, che puo' essere una tabella semplice o una query sql. La proprieta' .datafield serve per legare il controllo ad una colonna specifica. Consiglio di dare un'attenta occhiata all'help prima di lavorarci seriamente per non avere sorprese.
 

D:  ho un problema con il pacchetto di istallazione di un mio applicativo! Ho usato per accesso ai dati(db MS Access) l'interfaccia ADO, usando M$ Jet 3.51 come Provider... istallato il pacchetto e Mdac_typ.exe sul cliente, al momento dell'accesso al db mi da errore sul Provider... sapete quali altre librerie devo includere nel pacchetto?

ho avuto lo stesso problem anch'io e, dopo aver navigato un po su MSDN, ho scoperto che senza le DCOM 95, il pacchetto da te indicato non riesce a registrare alcuni componenti. Il file DCOM95.exe lo puoi trovare al sito web della microsoft (ma non so l'URL corretta) o, normalmente, nel cd di installazione di Internet Explorer 4 o 5.
 
 

D: c'è qualcuno che potrebbe spiegarmi la differenza tra OLE DB e ODBC?!? ...mi è rimasto qualche dubbio!

Questo e' quello che so io. Posso anche essere impreciso e se qualcuno mi corregge mi fa un piacere.
All'inizio per accedere a DBMS come Oracle o Informix avevi a disposizione le API che ognuno di questi esponeva. Ogni DBMS aveva le sue API specifiche, diverse da quelle degli altri.
ODBC (Open DataBase Connectivity) ha portato ad una standardizzazione di queste API.
Come?
Sicuramente non sostituendo le API preesistenti, perche' avrebbe comportato la non portabilita' di programmi scritti prima di ODBC. Quindi ODBC e' stato pensato come uno strato intermedio di API standard, tra le API del DBMS e le applicazioni richiedenti l'accesso al DB.
Esiste, per esempio un driver ODBC per Oracle di Microsoft e ne esiste anche uno della Oracle stessa (altamente consigliato); entrambi sono implementazioni della stessa funzionalita' : esporre alle applicazioni il set di API standard ODBC usando le API di Oracle DBMS.
OLE DB e', per me,  un mezzo mistero. Penso di averlo utilizzato ma senza saperlo perche' non so' esattamente dove inizia e dove finisce..
OLE e' la tecnologia che ti da' la possibilita' di aprire Excel inserire e formattare dei valori nelle celle stampare e chiudere, il tutto da un programma VB tramite una comoda struttura ad oggetti. OLE e' in pratica un protocollo (insieme di proprieta' e metodi) che tu puoi usare per parlare con Excel. Naturalmente questo e' possibile perche' Excel e' stato scritto in modo da poter ricevere queste richieste ( Excel e' un Server OLE) e farsi pilotare dall'esterno da VB.
Ne deduco che OLE DB sia l'accesso alle funzionalita' di un DBMS mediante uno schema ad oggetti. Uno strato posto sopra alle API ODBC che conferisce una visione ad oggetti dell'intero motore DB nonche' la capacita' di pilotarlo da "fuori".
E qui inizia il baratro della mia ignoranza:
A rigor di logica ADO e' OLE DB. Ma anche DAO allora e' OLE DB, in quanto visione ad oggetti del motore Jet, il quale poi, supportando ODBC, estende il modello DAO a tutti i DBMS di cui esista un driver ODBC sotto windows. E' Giusto?

P.S. Soccia che papiro.!!

R: Sono entrambi 2 modi "universali" per accedere ai database, nel senso che puoi usare la stessa API per accedere a db di diversi produttori usando, in linea di massima, lo stesso codice, appoggiandoti ad un driver sottostante che e' specifico per ogni db.
Sulle API ODBC sono state costruite le piu' amichevoli interfacce ad oggetti DAO e RDO per semplificare le cose.
OLE DB si basa su interfacce COM per l'accesso ai dati, non piu' su API di tipo funzionale, quindi nasce gia' ad oggetti.
Per semplificare OLE DB, e' stato costruito ADO, che nasconde i dettagli delle interfacce COM (anche quelle non troppo amichevoli, basta indagare un po' all'interno delle properties) e fornisce un metodo di accesso ai db piu' semplice.
Il driver di accesso ai db in OLE DB si chiama "provider", ma sempre di un driver si tratta.
La differenza piu' importante e' comunque che, mentre ODBC e' collaudato da diversi anni, OLE DB lo e' molto meno, quindi i provider OLE DB sono in genere meno affidabili dei corrispondenti driver ODBC (ancora utilizzabili anche con ADO).
Un triste esempio e' il provider OLE DB per Jet 3.51 fornito con VB6.
Sempre meglio controllare se un driver OLE DB supporta tutte (o almeno le piu' importanti) feature del db sottostante
 

D:  Ero solito usare i contatori e con DAO quando creo un nuovo record posso leggere quale numero viene assegnato.
Adesso con ADO quando creo un nuovo record non riesco a leggere il numero del campo contatore se non chiudendo e riaprendo il recordset. Ma a quel punto come faccio a sapere quale è il mio ?

R: Se usi jet e' un bug noto di ADO 2.0, ma non sono sicuro che in ADO 2.1 sia stato risolto. Dovresti controllare su MSDN online se trovi qualcosa.

R: Mauro dice che e` un bug conosciuto, ma... hai provato a posizionarti sullo stesso record con
recordset.move 0 ? (in DAO funzionava cosi`)
RR: Acc, ci speravo. Invece non funziona. Io mi connetto a SQLServer, forse funziona con il Jet
 
 
 

D:  Qual'è l'istruzione/procedura per aprire un DB Access protetto (di cui si sa ovviamente la password)?

R: Dim myDB as Database
    With DBEngine
        .SystemDB = App.Path & "\pippo.mda"
        .DefaultUser = "883"
        .DefaultPassword = "dovestazaza"
    End With
    Set myDB = Workspaces(0).OpenDatabase(App.Path & "\pippo.mdb")

D: Qual'è l'istruzione per stabilire se un Recordset è aperto o chiuso (riferire in DAO rigorosamente).

R: ammesso che rsTmp sia la variabile recordset:
If Not rsTmp Is Nothing Then ...