[VB6] Uso degli indici di SQL Server

[giustavalla]

Come selezionare un indice nell'ambiente VB6 e SQLSERVER EXPRESS ?
SQL Server Management Studio indica che nel mio database esistono degli indici a certe tabelle.
Non so però come selezionarli.
L'istruzione rs.index="PerCodice" da errore.
In altri ambienti (DAO ad esempio) questa istruzione produceva il risultato voluto.
Ecco come apro la tabella :

Set rs = New ADODB.Recordset
   rs.CursorLocation = adUseServer
   rs.Open "TabAnalisi", CnnSQL, adOpenDynamic 
   rs.Index = "PerCodice"

Dove sbaglio ?
Grazie per l'attenzione.

[optime]

sql server seleziona da sé gli indici -- ovviamente se li hai predisposti nel db...

[giustavalla]

Io credo che si debba scegliere quale fra i 2 o 3 indici bisogna utilizzare, prima dell'istruzione Seek.
Esempio
rs.Seek "=", "EMOC"
oppure, con indici multipli
rs2.Seek "=", 123, 666
Con DAO era così (sto convertendo un progetto che utilizza MSAccess con DAO e ADO in SQLServer)
Ma sembra che il provider da me utilizato non preveda gli indici (ne il Seek)

StringaConnessione = "Provider=SQLOLEDB.11;Data Source=SEVEN\SQLEXPRESS;Initial Catalog=WinAnaSQL2018;Integrated Security=SSPI;Persist Security Info=False;"

Quale provider utilizzare quindi ?

[giustavalla]

Per maggiore complessione del mio problema (che spero prima o poi di risolvere) aggiungo 2 spezzoni di codice
1) con MSAccess e DAO

rsPrezziClienti.index = "PerAIDCID"
For i = 56 To 100
          CID = CLng(Val(LbSiglaCliente(i - 56).Tag))
          If CID > 0 Then
                rsPrezziClienti.Seek "=", AID, CID
                if Not rsPrezziClienti.NoMatch Then
                      Tx(i).Text = rsPrezzoClienti("Prezzo"))
                end if
          end if 
Next i

2) con SQLSERVER e ADO

For i = 56 To 100
          CID = CLng(Val(LbSiglaCliente(i - 56).Tag))
          If CID > 0 Then
             rsP.Open "SELECT * FROM TabPrezziClienti WHERE AnalisiID=" & CStr(AID) & " AND ClienteID=" & CStr(CID), CnnSQL
              if rsP.EOF Then
                      Tx(i).Text = rsP("Prezzo"))
             end if
          end if 
          rsP.close 
Next i

Orbene, la differenza (in termini di tempi di esecuzione, è notevole: praticamente istantanea nel primo caso e poco meno di 1" nel secondo caso).

[optime]

è sempre un azzardo confrontare DAO/Access e ADO/SQLServer, soprattutto sulla query secca e magari in locale (te lo dico per esperienza)

detto questo, AnalisiID e ClienteID sono indicizzati su SQL Server?

P.S. 1
dovrebbe essere if NOT rsP.EOF Then invece di if rsP.EOF Then

P.S. 2
butta un occhio qui
https://docs.microsoft.com/it-it/sql...ql-server-2017

P.S. 3
puoi anche usare delle Stored Procedures invece delle query cablate nel codice

[giustavalla]

Grazie del supporto.
Il confronto che ho fatto io è sui tempi di esecuzione, oltrechè di semplicità del codice (tutti a favore di DAO, ahimè).
L'indice esiste realmente su SQLServer; l'ho verificato con SSMS. Precisamente, per la tabella in questione, esistono 2 indici "univoci non cluster" ed 1 indice "cluster").
Il messaggio di errore è "Il provider corrente non supporta l'interfaccia necessaria per la funzionalità Index".
Il codice dell'esempio è stato scritto al volo modificando un pochino il vero codice; è un errore "di sbaglio".
Credo di aver letto tutto o quasi quello che riguarda gli argomenti "VB6 SQL SERVER INDEX". In particolare le stringhe di connessione elencate in www.ConnectionString.com.
Non conosco nulla delle "Stored Procedures"; non vorrei aggiungere un ulteriore elemento di complessità a quanto già sto facendo.

[optime]

se devi lavorare in locale con un database ridotto (ridotto=non stiamo parlando di milioni di record) non c'è nessun beneficio - se non di aggiornamento tecnologico - a passare a ADO/SQL Server: il confronto con DAO/Access sarà sempre impietoso

[giustavalla]

Purtroppo l'MDB di Access (50 MB, una ventina di tabelle con qualche migliaio di record ciascuna) ogni 3 o 4 mesi si inchioda, al contrario di un altro applicativo simile (sempre da me realizzato con SQL Server) che è indenne da questi inconvenienti. E poi un po' di aggiornamento tecnologico (come dici tu) non guasta.
Spiace però constatare che qualcosa non si riesce (o io non riesco) a migliorare, anzi.
Altre idee ?

[URANIO]

Il problema è nella logica non gli indici.
Nel primo esempio scarichi tutta la tabella in memoria e poi la cicli, nel secondo esempio esegui in totale 50 query.
Se vuoi fare come il primo esempio ti scarichi tutta la tabella, tipo "Select * from tabella", e poi cicli all'interno del recordset.

[gibra]

Io non ho mai usato DAO, ma sempre e solo ADO 2.8 (ADODB) rigorosamente senza il famigerato controllo ADODC (corrispondente al DataControl di DAO) e non ho mai avuto problemi.
Tutt'ora ho un vecchio programma realizzato nel 2004 (Gestione Studio) usato in uno studio commercialista da 10+ di utenti sia in rete locale che in Terminal Server e non si è mai (ripeto MAI) piantato.
In realtà i database che vengono gestiti sono 4 (quello dei dati e gli altri 3 sono solo tabelle statiche)
L'unica accortezza è quella di compattare il db dei dati ogni giorno. Null'altro.

Scusa la franchezza, ma dei due spezzoni di codice che hai mostrato, io non ne farei nemmeno uno!
Non mi pare per nulla un'approccio efficiente. Anzi!

Per non parlare poi di un SELECT * per recuperare un singolo dato!