Domanda

Sto cercando di estrarre una tabella di valori da un foglio di calcolo Excel (2003) usando vb6, il cui risultato deve essere archiviato in un recordset (adodb). La tabella è simile alla seguente:

    Name   Option.1  Option.2  Option.3  Option.4  Option.5  Option.6 
    -----------------------------------------------------------------
    Name1         2         3         4
    Name2         2         3         4
    Name3         2         3         4
    Name4         2         3         4
    Name5         2         3         4
    Name6         2         3         4
    Name7         2         3         4
    Name8         2         3         4
    Name9         2         3         4         5         6         7  

Al momento della connessione e dell'esecuzione della query " SELEZIONA * DA [Foglio1 $] " o persino una colonna specifica, " SELECT [Opzione # 6] DA [Sheet1 $] " (vedi nota 1) e analizzando i risultati, mi vengono dati i valori Null per la riga Name9 , Option.4 - > Opzione.6 anziché i valori corretti 5, 6 e 7. Sembra che la connessione al foglio di calcolo stia utilizzando una "migliore ipotesi" di decidere quali sono i limiti di tabella validi e tiene conto solo di un determinato numero di righe.

Per connettermi al foglio di calcolo, ho provato entrambi i provider di connessione Microsoft.Jet.OLEDB.4.0 e MSDASQL e ho riscontrato lo stesso problema.

Ecco le impostazioni di connessione che utilizzo:

Set cn = New ADODB.Connection
With cn
    .Provider = "Microsoft.Jet.OLEDB.4.0"
    .ConnectionString = "Data Source=" & filePath & ";Extended Properties=Excel 8.0;"
    - - - - OR - - - - 
    .Provider = "MSDASQL"
    .ConnectionString = "Driver={Microsoft Excel Driver (*.xls)};" & _
                        "DBQ=" & filePath & ";MaxScanRows=0;"
    .CursorLocation = adUseClient
    .Open
End With  
Set rsSelects = New ADODB.Recordset
Set rsSelects = cn.Execute("SELECT [Option#5] FROM " & "[" & strTbl & "]")

Questo problema si verifica solo quando sono presenti più di 8 righe (esclusi i nomi delle colonne) e ho impostato MaxScanRow = 0 per la connessione MSDASQL , ma questo ha ha prodotto gli stessi risultati.

I riferimenti importanti al progetto che ho incluso sono:

  • Libreria MS ActiveX Data Objects 2.8
  • Libreria MS ActiveX Data Objects Recordset 2.8
  • Libreria oggetti di MS Excel 11.0
  • MS Data Binding Collection VB 6.0 (SP4)

Qualsiasi aiuto in questa materia sarebbe molto apprezzato!

(1) Per qualche motivo, quando si include un punto decimale nel nome della colonna, viene interpretato come #.


Grazie a tutti! A metà strada nel tentativo di impostare un Schema.ini "a livello di codice" da KB155512 onedaywhen è eccellente post mi ha indicato la soluzione:

.Provider = "Microsoft.Jet.OLEDB.4.0"
.ConnectionString = "Data Source=" & filePath & ";Extended Properties=""Excel 8.0;HDR=Yes;IMEX=1"";"

Vorrei incoraggiare chiunque abbia problemi simili a leggere il post e i commenti, poiché ci sono lievi variazioni in una soluzione da una persona a un'altra.

È stato utile?

Soluzione

Hai ragione: sta indovinando il tipo di dati basato su un numero di righe. Esistono chiavi di registro del computer locale che è possibile modificare per influenzare il tipo di dati scelto. Per maggiori dettagli, vedi questa risposta .

Altri suggerimenti

Il driver ISAM di Excel per impostazione predefinita esamina la prima manciata di righe e indovina il loro tipo di dati. Se ci sono (più avanti nella tabella) dati che non rientrano nel presupposto iniziale, si acciglia e li trasforma in NULL.

L'impostazione MaxScanRows = 0 è la chiave di questo problema. Sembra che farebbe la cosa giusta (scansiona l'intera tabella per il tipo di dati da usare), ma in realtà non lo fa.

Vedi onedaywhen per ulteriori informazioni dettagli, le mie prime informazioni su KB282263 non sono state il consiglio corretto.

Il miglior consiglio che posso darti è di smettere di farlo nell'ambiente VB6. Apri Excel, premi ALT + F11 e carica l'IDE VBA. Inserisci il tuo codice lì dentro. Dall'interno di questo ambiente è possibile accedere al modello di oggetti Excel completo.

Ho visto molte persone provare ad interagire con Excel in molti modi diversi e hanno tutti problemi. L'utilizzo della macro VBA o del metodo del componente aggiuntivo è il modo migliore che ho trovato per ottenere i dati. È così che Microsoft ottiene Excel e Project da integrare con TFS.

A volte è necessario ripensare un po 'il processo affinché questo approccio sia adatto. Per esempio. Potrebbe essere necessario ottenere l'utente che sta utilizzando il foglio di calcolo per eseguire una macro che espellerà i dati dal foglio di calcolo anziché eseguire un processo per estrarre i dati dal foglio di calcolo, ma in genere è fattibile.

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top