Newsgroup: it.comp.lang.visual-basic
Titolo: [?]Tipo non corrispondente, spiegatemelo.....

Nella form/modulo xy ho una procedura tipo
Public Sub Initrs(rs as recordset)
[.......]
In un evento della form qw succede questo:
dim rs as recordset
    [.........]
    call xy.initrs(rs)
Perchè il tipo non è corrispondente?
Sono due RECORDSET, uguali in tutto e per tutto!
Con la certezza di essere di fronte a uno di quei problemi che paiono
assurdi ma si risolvono con una cavolata di accorgimento porgo distinti
saluti ^_^

    call xy.initrs(rs)
Cos'hai referenziato? DAO? ADO? Entrambi? Specifica in fase di dichiarazione se si tratta di un
oggetto recordset ADO o DAO...
Prova ad esempio:
Public Sub Initrs(rs as recordset)
msgbox typename(rs)
end sub
Dim rs as adodb.recordset
call xy.initrs(rs)
il msgbox ti dirà che rs è "Nothing", poiché è stato dichiarato il tipo ma non istanziato l'oggetto
Prova ora ad aggiungere:
Dim rs as adodb.recordset
set rs = new adodb.recordset
vedrai che la msgbox ti dirà "Recordset"
Dai un'occhiata se nella parte [.........] hai commesso una "mancanza" di questo tipo... altrimenti,
prova a postare la parte di codice omessa...
Ciao,
Moreno
#sirri#@#
morenosoft.com#
(togliete "#" dall'indirizzo)
Moreno Sirri VB Site - 
http://www.msvbsite.net
---------------------------------------------------------------------------
Le risposte alle tue domande le trovi sul Sito Comune di questo NewsGroup:
 
http://www.it-lang-vb.net
---------------------------------------------------------------------------

Nirvana wrote:

Hai provato con
Public Sub Initrs(ByRef rs as recordset) ?
Bye by Massimo 8-]

 Public Sub Initrs(ByRef rs as recordset) ?
provato ora.
byRef e byVal: niente.
e un'altra newsletter appena postata contiene lo stesso identico problema, e
non sono io.

 Sono due RECORDSET, uguali in tutto e per tutto!
[SNIP]
Non e' che per sbaglio hai incluso nel tuo progetto piu' riferimenti a
librerie che definiscono la classe recordset (ad esempio DAO e ADO insieme)?
Prova a modificare le tue dichiarazioni con 'ADO.Recordset' o
'DAO.Recorset', a seconda di quello che usi, al posto di 'Recordset' e vedi
se funziona, se e' cosi' allora il problema e' proprio quello...
Ciao
--
Luca Dormio
luca....@tin.it

 se funziona, se e' cosi' allora il problema e' proprio quello...
Ouch.
Ecco cosa mi mancava.
Non so che differenza passi tra ADO e DAO.
In genere uso codice tipo questo
dim db as database
dim rs as recordset
set db=opendatabase("path", False, False, "pwd=pirulero")
set rs=db.openrecordset("SELECT ecc ecc")
[.......]
Mi collego sempre a database ms Jet, quelli di Access per intenderci.
Sono recordset DAO o ADO?
Che differenza cč?
Grazie.

 ha scritto nel messaggio
news:Gca97.26318$0Z1.1...@news.infostrada.it...

Fai come ti ha detto Moreno:
Public Sub Initrs(rs as ADODB.recordset)
ciao
ugo


Me ne manca un pezzo.
Mi dice "Tipo definito dall'utente, non definito".
Cosa devo scriverci prima?
Se mi accennaste anche la differenza che cè tra ADO DAO e ADODB mi
rendereste estremamente felice.
Anzi, no, gaudio ed entusiastico ^_^.


Direi che se ti dice cosě stai usando Dao, quindi:
Public Sub Initrs(rs as DAO.recordset)
Spiegazioni:
Su Msdn trovi valanghe di articoli sulle diverse tecnologie di acceso
dati...
ciao
ugo

 Public Sub Initrs(rs as DAO.recordset)
Non mi dice più "Tipo non definito" ma pur essendo entrambi i recordset
definiti come DAO.recordset sono ancora "Tipo non corrispondente"
Pero' ho imparato qualcosa di nuovo, che bello.


Allora, come ti ha detto Moreno, hai dei riferimenti doppi.
Controllali e definisci anche nella proc chiamante rs come DAO.recordset
ciao
ugo

 Sono recordset DAO o ADO?
sono recordset DAO, quindi dovresti assicurarti di avere nei riferimenti
solo
'Microsoft DAO 3.x Object Library'
e *togliere* righe del tipo
'Microsoft ActiveX Data Object 2.x library'
a questo punto gurada se funziona...
ciao
--
Luca Dormio
luca....@tin.it

 Controllali e definisci anche nella proc chiamante rs come DAO.recordset
Eh eh, iniziano a esserci un sacco di reply, probabilmente sono io che sono
ignorante forte.
Una mezza cultura su MSDN me la sono fatta pero' a riguardo ADO e DAO e RDO.
Ho creato un progettino apposta e ho cercato di semplificare il tutto al
massimo.
Ho usato solo oggetti DAO, sia per i recordset, tutti, che per il database.
E il listato integrale dell'esempio semplificato, riferimenti al database e
alle tabelle esclusi.
Private Sub Command1_Click()
Dim db As DAO.Database
Dim rs As DAO.Recordset
    Set db = DAO.OpenDatabase(****)
    Set rs = db.OpenRecordset(****)
    init (rs)
End Sub
Private Sub init(rs As DAO.Recordset)
    If Not (rs.EOF And rs.BOF) Then
        rs.MoveLast
        rs.MoveFirst
    End If
End Sub
Non va, come al solito, "Tipo non corrispondente", e stavolta direi che sono
DAVVERO gli stessi...... forse.
Ho fatto una cosa analoga con l'ADODB usando un sorgente gia preimpostato e
già connesso trovato sul sito comune. Tutte le variabili erano ADODB, non va
uguale.
Il problema piu' grosso è che ho la testa dura, e quando ho un problema, per
principio, la sbatto finchè il piccì non riprende a funzionare come dico io.
Qui però non so che fare. Se voi riuscite a farlo andare provatemi a passare
direttamente un sorgente funzionante.
In teoria sono meno di 20 righe, ci mettereste un secondo a verificare, però
non si muove....
Un'altra cosuccia.
Ho visto che ADODB non supporta i l'oggetto Database ma solo Connection.
In DAO invece si usa princialmente Database e Recordset pur essendoci anche
Connection.
MSDN dice che ADO è nuovo, su certi aspetti migliore ma non supporta tutto.
Secondo voi mi conviene continuare a usare DAO come (senza saperlo) ho
sempre fatto o mi conviene passare ad ADO?
Complimenti per la pazienza......

 Perchč il tipo non č corrispondente?



Qui Pal mi spella...   :-)
Lascia perdere Dao sui progetti nuovi.
Ado è
1) Supportato a differenza di Dao che sarà abbandonato a breve
2) Portabile essendo identico l'uso degli oggetti anche su database diversi
(fatte salve le solite differenze tra provider dati)
3) Più performante in ambiente di rete
4) Più lineare come struttura del modello oggetti e di conseguenza più
"elegante"
...
(Presto questa diventerà una risposta generica)
ciao
ugo

Allora, come ti ha detto Moreno, hai dei riferimenti doppi.
e 2.... :-) non mi caga proprio... :-))))


 Lascia perdere Dao sui progetti nuovi.
pal proprio non ci pensa, tesoro. pal ha gia' zittito un altro caro
amico del ng mandandogli tempi e statistiche, e adesso j e pal stanno
boccheggiando davanti a un pigro ventilatore. c'e' troppo caldo per
mettersi anche a spellare qualcuno :))
a spellarti ci pensera', e con un rasoio poco affilato se non proprio
arrugginito, nirvana, se il suo e' un db monoutente e in locale, se non
dovra' mai connettersi ad altro che access e altrove che sul suo pc o su
un serverino negli immediati dintorni con utenti <= 3/4 (leggasi tre o
quattro, non tre quarti), quando vedra' le prestazioni di ado ottenute
in cambio di una compatibilita' democratica e del tutto inutile.
se invece deve connettersi a un db mysql o postgres su un server n*x, o
se vuole soffrire a scopo ascetico e di evoluzione spirituale, i
lehrjahre su ado saranno utilissimi. lehrmonate, anzi, se il mio tedesco
regge. perche', appena l'avra' imparato, ms avra' gia' tirato fuori
NetDO. ma che importa ? imparando si impara a imparare...
eheheh.
nirvana, a parte tutto, non stare a sentire pal. ascolta ugo. specie se
stai imparando. ma, specie se il tempo che puoi dedicare
all'apprendimento non e' infinito, come prima cosa non chiederti casa
devi imparare, ma cosa devi fare. su quello ti regoli. con un granello
di sale.
il caro amico si e' detto disposto a dare a pal ripetizioni private su
ado. l'ignaro non sa che il giovane pal era convinto che cartesio fosse
un empirista. e che tutto sommato, e dopo tanti anni, lo e' ancora :)
ciao, a.

  End Sub
Ragazzi, un monumentone a tutti per la pazienza, ma con me è a chi trova
l'errore piu' piccolo.
Vi dirò, perlomeno mi sono fatto una cultura di ADO e DAO, che mi mancava,
però se non fosse stato per Ugo saremmo andati avanti a vita.
Il problema era SOLO nel modo di passare i parametri. Ho controllato, anche
senza le dichiarazioni esplicite ADODB o DAO e senza le due parantesi
funzionava perfettamente.
Si poteva anche scrivere
call init(rs)
Però la motivazione strettamente teorica e la differenza tra i due modi di
passare lo stesso parametro mi manca.
Complimenti a Ugo per la vista e grazie a tutti, questo è il secondo
problema che mi risolvete in due giorni che conosco questa mailing e il
relativo sito comune e ho già imparato più di quanto non volessi imparare.
Per quanto riguarda l'ADO, a parte il modo di connettersi alle tabelle che
non è un db.openrecordset ma agisce sull'oggetto connection, poi tutto il
resto è lo stesso? (proprietà e metodi dell'oggetto recordset, dai move al
recordcount per intenderci)?

 passare lo stesso parametro mi manca.
Res = Funzione(parametri)
Call SubOFunzione(parametri)
Sub [parametri]
Altrimenti si rischiano casini (io preferisco le prime due).
Ecco il perchč:
Sub MiaFunc(ByRef i As Long)
    ' ** nota il ByRef **
    i = i +1
End Sub
Dim i As Long
MiaFunc i
Debug.Print i
Call MiaFunc(i)
Debug.Print i
MiaFunc(i)
Debug.Print i
Risultato strano nell'ultimo passaggio eh?
Un retaggio del buon QBasic DOS.
L'ultima Sintassi equivale a
Call MiaFunc(ByVal i) ' E sě! si possonoo forzare i passaggi ByVal!
Ciao


Absolutely not!
Sono simili, ma non uguali...
E in particolare metodi e proprietà sono soggetti alle specifiche del
provider dati... quindi leggiti un po di teoria di Ado su Msdn o i primi
tentativi di utilizzo ti sembreranno un incubo...
ciao
ugo


Digito ergo sum...?
ciao
ugo