Newsgroup: it.comp.lang.visual-basic
Titolo: alternativa a recordcount

ciao
che alternativa posso utilizzare al posto della proprietą recordcount
per sapere se sono presenti record?
grazie
La mente non ha bisogno, come un vaso, di essere riempita, ma piuttosto, 
come legna, di una scintilla che l'accenda vi infonda l'impulso della ricerca 
e un amore ardente per la verita'.
					 Plutarco, L'arte di ascoltare.

 per sapere se sono presenti record?
Io uso:
If not cbool(Rcs.State and Adstateopen) then
    call msgbox("Recordset non aperto")
    exit sub
endif
If Rcs.EOF and RCS.BOF then
    call msgbox("Recordset vuoto")
    exit sub
else
    call msgbox("Recordset non vuoto")
endif
Ciao
Alberto

 grazie
un recordset vuoto ha vere entrambe le proprietą eof e bof
Salutoni
Sergio

 per sapere se sono presenti record?
Per evitare equivoci:
A te interessa sapere se sono o no presenti records (in tal caso, come ti
hanno consigliato, se BOF e EOF sono entrambi veri il recordset č vuoto) o
_quanti_ records sono presenti? In questo secondo caso, con che database?,
con DAO o con ADO?, con che tipo cursore e da che lato (nel caso di ADO)?

 per sapere se sono presenti record?
Un'alternativa al recordcount e alle proprietą BOF e EOF ... č
AbsolutePosition = -3
Saluti

>A te interessa sapere se sono o no presenti records ?
Sě, cercavo questo
grazie a tutti


 AbsolutePosition = -3
Mmmmmhhhhh
AbsolutePosition=adPosEOF (ossia 3) equivale a RCS.EOF=True, che da solo non
è sufficiente a sapere se il recordset è vuoto o meno.
Ciao
Alberto


Vero ma se apro un recordset ADO sono subito posizionato al primo record
quindi se Rst.EOF = true non ci sono record.
Ciao
max

 ha scritto nel messaggio
news:JBIf9.11142$Oz2.2...@twister2.libero.it...

Opsss... scusate volevo dire -1 (adPosUnknow)

 quindi se Rst.EOF = true non ci sono record.
Giusto.
Ma il thread chiedeva come determinare se un recordset è vuoto,
indipendentemente che tu il test lo voglia fare subito dopo il .Open o dopo
due ore.
Usare .Eof va bene, effettivamente, solo appena eseguito il .Open
Oltretutto, se il recordset è bound a qualche controllo, può darsi che non
vada già più bene perchè dopo l'Open il controllo bound esegue qualcosa
prima del tuo check, e ti porta il bookmark su EOF anche se hai 1000 record.
Ciao
Alberto

 ha scritto nel messaggio
news:3d7f594c...@192.168.0.76...
Cut
Mah !
Mi sarà sempre andata bene in questi anni?
rs.open
If rs.bof then
    "NADA DE NADA"
else
 "c'è qualcosa"
End if
Saluti....
....sempre maestri a metter dubbi eh????? eh! eh! :o)

 prima del tuo check, e ti porta il bookmark su EOF anche se hai 1000
record.
Ecco. La regola dice di testare sia BOF che EOF, sempre e ovunque.
Mi pare che dica anche di non usare _mai_ funzioni di approssimazione...

 ha scritto nel messaggio
news:ptKf9.93054$pX1.3...@news2.tin.it...

Immagino intendessi "If rs.Eof then...", perchè Bof è sempre vero dopo
l'apertura del recordset.
Il punto è un altro:
L'apertura di un recordset è un'operazione molto più complessa di quanto si
creda.
Se si vuole stare tranquilli ed intercettare tutte le situazioni sfortunate,
la cosa migliore è creare una function del tipo Apri_Recorset, a cui passare
il puntatore al recordset, alla connection, la connectionstring (da usare se
la connection è chiusa e deve essere riaperta), e la Source.
La function restituirà un long con il numero di record ritornati, oppure 0
se il recordset è vuoto, oppure un numero negativo che indica l'errore
avvenuto.
A questo punto, avendo una funzione di questo tipo, l'apertura del recordset
diventa molto semplice.
Il problema è che, un domani, tu potresti utilizzare una funzione di questo
tipo per aprire un recordset che è bound ad un controllo (ad esempio un
datagrid). Ecco il primo problema.
Se il controllo esegue qualcosa sugli eventi, questo qualcosa potrebbe anche
spostare il bookmark del recordset su EOF, e se da qualche parte c'è un
DoEvents, ti ritrovi Rs.Eof=True anche se il recordset è ben pieno.
Ovviamente, nel 99.9% dei casi è sufficiente testare solo rs.Eof, ma quando
si scrive del codice, e si vuole che sia riutilizzabile in altri contesti,
deve essere scritto prendendo in considerazione che possono esistere tante
situazioni diverse.
Ciao
Alberto

 ha scritto nel messaggio
news:9rgg9.4423$eG6....@twister1.libero.it...
EHM NO NO !
Carissimo Albe V° ti assicuro che FORSE la teoria sarà così ma la pratica è
diversa (ma credo che anche la teoria sia diversa)....
siccome può essere la tua parola contro la mia.....e siccome in tutti questi
anni non mi sono rincoglionito!...e i miei programmi continuano a
funzionare!
Riferimenti ADO 2.7 (ho winxp pro!)
VB6 Sp5
Access 2000
Database chiamato DBtest.mdb Tabella: Anagrafica dentro quello che ti pare
con però un campo testo chiamato Nome
Una form e 2 pulsanti...dentro questo codice!
Option Explicit
Dim cn As New ADODB.Connection
Dim rs As New ADODB.Recordset
Private Sub Command1_Click()
'condizione vera
Dim TSQL As String
TSQL = "SELECT * FROM Anagrafica"
rs.Open TSQL, cn, adOpenKeyset, adLockReadOnly
If rs.BOF Then
    MsgBox "Recordset Vuoto"
    rs.Close
    Exit Sub
End If
rs.MoveLast
MsgBox "Ci sono " & CStr(rs.RecordCount) & " record(s)"
rs.Close
End Sub
Private Sub Command2_Click()
'condizione falsa
Dim TSQL As String
TSQL = "SELECT * FROM Anagrafica WHERE Nome='INESISTENTE'"
rs.Open TSQL, cn, adOpenKeyset, adLockReadOnly
If rs.BOF Then
    MsgBox "Recordset Vuoto"
    rs.Close
    Exit Sub
End If
rs.MoveLast
MsgBox "Ci sono " & CStr(rs.RecordCount) & " record(s)"
rs.Close
End Sub
Private Sub Form_Load()
cn.ConnectionString = "Provider=Microsoft.Jet.OLEDB.4.0;Data Source=" &
App.Path & "\dbtest.mdb"
cn.CursorLocation = adUseClient 'inutile per Access
cn.Open
End Sub
..........CIAO!
:-)
la ragione è che quando apre un recordset va a cercare subito un record
valido....quindi NON punta a BOF ma al primo record valido!...se non lo
trova...non esiste e quindi punta a BOF.....di eof me ne frego!...in realtà
io faccio(nei miei programmi) rs.movefirst solo per sicurezza, per eccesso
di scrupolo...è ridondante!

 rs.Open TSQL, cn, adOpenKeyset, adLockReadOnly
Facendo così, tu non testi lo stato della connessione.
Ciò può andare bene in locale, ma appena si lavora in rete, la caduta di
rete è un evento tutt'altro che improbabile.
Con questa modalità, se la connessione è caduta ma può essere ripristinata,
tu non intervieni e l'applicativo va in errore, anche se in realtà tutto
potrebbe ristabilirsi correttamente senza problemi per l'utente.
Se un domani tu passassi a Sql-Server, che non supporta il
PersistSecurityInfo, il codice deve essere scritto tenendo in considerazione
che la caduta di rete può avvenire in ogni momento, e che la connessione
deve ripristinarsi.
Pensa che i miei applicativi sono stati testati staccando gli hub, facendo
il reboot dei server, ecc,. mentre i client erano attivi. Ovviamente durante
il periodo con rete staccata, il client segnalava l'impossibilità di
reperire informazioni, ma appena la rete tornava utilizzabile, l'utente
tornava a lavorare senza dover riavviare niente.
Comunque quella del Bof dopo l'Open non la sapevo...
Però riflettendoci è logico, perchè Eof è un record valido, mentre Bof non è
valido...
Grazie.
Ciao
Alberto

 valido...
Questa non la sapevo, sei sicuro che sia così?
Salutoni
Sergio

 ha scritto nel messaggio
news:_dhg9.89192$ub2.1...@news1.tin.it...

No.
Adesso faccio qualche prova.
Il problema è che sono talmente poco abituato a testare solo una delle due
condizioni, che non escludo di dire cavolate.
Ciao
Alberto

 EHM NO NO !
Ad integrazione e per non essere frainteso....Microsoft consiglia di testare
EOF e BOF  è vero!.....soltanto che un giorno non testai eof...tutto
funzionava...ci ragionai un po sopra ...e....forse mi è sempre andata bene!
Persist security info....
non la uso su programmi monoutente...questo era un esempio per
rs.open....quindi....
Se affrontiamo il discorso della connessione ...beh diventa spinoso in
quanto fa veramente cacare...ops schifo!...il controlo della connessione che
abbiamo sotto VB.....anzi sotto ADO....al di la di un adstateopen non si
va!....
Soluzione mia:
Apri/chiudi....che in ado fa anche bene!
oppure
Flag da testare..e gestione dell'errore su una tabellina connAttive...fa
pena ma questo è quanto abbiamo!
Saluti!
:o)

 Apri/chiudi....che in ado fa anche bene!
In Ado non so. Ricordo che con Dao un mio collega dovette rinunciare a
questa cosa perchè dopo alcune migliaia di apri-chiudi di un Mdb in rete, il
db stesso risultava lockato e non si apriva più.
Utilizzando Ado, io uso la connessione esistente se è valida, altrimenti la
riapro.
Del resto, aprire una connessione per ogni Recordset (non so se è il tuo
caso) sarebbe un suicidio in quei sistemi DB che contano le licenze.
Se cerchi, troverai parecchi thread di gente che ha esaurito le licenze di
Sql-Server con pochi utenti connessi.
Ciao
Alberto

 news:jzhg9.101204$pX1.3...@news2.tin.it...
In questo campo "spinoso" ci sto arrivando ora....ADO come ho già detto in
vari post passati HA il "pool di connessioni" che fa riusare una conn e
quindi sotto ADO è conveniente aprire e chiudere conn....dovrebbe riusare
una conn "vecchia" e non farti sprecare licenze....
quindi (ma per programmini monoutente me ne frego eh!..sbagliando!)
Apro conn
Apro recordset
Disconnetto
Lavoro disconnesso
Riconnetto
Controllo concorrenza
Aggiorno
Risconnetto....come si fosse su internet!
A parte jet che ha "finezze" tutte sue(ma non è male anche sotto jet) quindi
conviene (sopratutto in rete) aprire e chiudere il piu' presto possibile
conn e recordset
Piano piano ...ma a parte il tempo....l'ho da digerire bene....voglio
arrivare al 3tier...e allora c'è lo strato intermedio (con un EXE Active)
che si occupa di gestire gli utenti e risolvere le concorrenze (ora le
lascio fare al motore db)...ma ancora ho da studiare!
Ciauz!
:-)