Access 97 su vb6

[LuigiDH]

Buonasera a tutti,
ho installato su un sistema operativo windows 8 un .exe (realizzato da me) che utilizza dei dati prelevati da un database fatto in access 97.
In xp installando il componente jet351 il software leggeva bene il database, ma con windows 8 niente da fare, ho provato ad installare il jet35sp3 ma niente ancora.

La prima volta che ho avviato il software mi ha dato l'errore: PRB: CLSID {00000010-0000-0010-8000-00AA006D2EA4

che non ha più dato dopo aver installato la dll con nome DA350.dll, adesso invece mi da sempre l'errore: the data binding DLL, 'VB5DB.DLL', could not be loaded.
Questa dll non la installa....Non so perchè.

Qualcuno mi saprebbe dire cosa devo aggiungere? Comunque inserire ocx, dll necessari per poter leggere questo benedetto access da qualsiasi pc non solo xp.

Grazie per l'aiuto

[optime]

visto che il prg l'hai fatto tu, passa ad ADO invece di DAO e sei a posto!

http://www.visual-basic.it/Forum/tab...x#.VglwC8vtlHw

[oregon]

VB6 con mdb Access97 e DAO ... la preistoria ...

Se proprio non vuoi seguire il consiglio di optime, crea un pacchetto di installazione ed eseguilo sul PC di destinazione ... (ovviamente NON usare l'installer fornito con VB6 ...)

[LuigiDH]

Grazie, per le risposte.
Siccome mi piace stare nella preistoria...(comunque mi trovo costretto ad utilizzare vb6, DAO pensavo mi semplificasse le cose per il caricamento dei dati), il pacchetto l'ho creato con install creato Pro, mi manca la dll o qualcosa che mi faccia funzionare il database access 97 in win8, esiste oppure devo modificare tutto? Ci sarà un modo!?
In alternativa cosa bisogna fare per passare ad ADO, modificare tutti i database che ho creato + il codice?

[optime]

con ADO non modifichi il db (che resta lo stesso), ma gli accessi. il grosso (per quanto mi posso ricordare) è che non hai più il metodo .seek

[gibra]

Capisco che a volte si è costretti a stare nella 'preistoria', d'altra parte però occorre prendere atto che non sempre è possibile utilizzare componenti preistorici ed allo stesso tempo pretendere di usarli nei nuovi sistemi operativi.
Avere la botte piena e la moglie ubriaca non è sempre possibile.

Vediamo se si riesce ad aggiornare quel tanto da poter eseguire il programma anche in Windows 8.x.

Prima di tutto devi aggiornare le tue informazioni (anche per il futuro) leggendo questo documento:
Support Statement for Visual Basic 6.0 on Windows Vista, Windows Server 2008, Windows 7, Windows 8 and Windows 8.1, Windows Server 2012, and Windows 10
https://msdn.microsoft.com/en-us/vstudio/ms788708.aspx

Vedrai che il Jet35 non è più supportato.

DAO?
Forse (non uso DAO per cui le mie indicazioni potrebbero non corrispondere a verità) per continuare ad usare DAO dovresti aggiornare il tuo programma al Jet36.
In tal caso, se ti è possibile, migrerei da Access97 a Access2000 o meglio ancora Access2002.

ADO?
Se pensi di migrare ad ADO (raccomandato) le cose sono un po' diverse, dato che DAO e ADO sono completamente differenti.
Solo il nome degli oggetti sono simili, ma il loro utilizzo e le loro potenzialità sono totalmente diverse.
In DAO hai un set completo per manipolare le strutture degli oggetti specifici di Access (Tabelle, Campi,..) cosa che ADO non ha, essendo pensato NON per Access ma per un uso più universale.
Per ADO si usa ADOX:
Microsoft Access tips: ADO Programming Code Examples
http://allenbrowne.com/func-adox.html

Con ADO puoi accedere a qualsiasi database, inclusi quelli di Access 2007 in poi (*.accdb)

Il vantaggio di usare ADO è che la versione 2.8 è già pre-installata in tutte le versioni di Windows (la v2.5 già da Windows 2000) così non devi preoccuparti di distribuire nulla.
Al contrario con DAO è più complicato: se, da come sembra, distribuisci il programma a terzi, nel tuo setup devi allegare l'installazione di DAO in tutte le versioni possibili.
Infatti ne esistono una per ogni versione di Windows che oltre a questo deve essere anche localizzata nella lingua del sistema operativo.
Non è finita: devi anche istruire il tuo installer ad installare quella corretta a seconda dell'ambiente che trova.
Naturalmente il tuo installer dovrà essere in grado di consentire di allegare i vari pacchetti di setup distribuiti da Microsoft fatti apposta, individuare l'ambiente sottostante e consentirti di parametrizzare quale setup usare.

La migrazione da DAO ad ADO non è difficile ma può essere articolata, tenendo conto delle varie differenze nell'uso degli oggetti ADODB, e soprattutto nei caratteri jolly diversi utilizzati dai due nelle query.

Comunque, prima di ogni cosa, è assolutamente indispensabile fare dei test su macchine virtuali (delle varie versioni di Windows) per vedere sia come funziona il programma, sia come funziona il setup (che deve essere perfetto).
Personalmente ho due macchine virtuali per ogni versione di Windows:
- una pulita che uso per testare l'installazione e l'esecuzione del programma
- una con l'IDE che uso per lo sviluppo e debug del programma, solo nei casi in cui lo stesso si comporti diversamente in quell'ambiente operativo.

[LuigiDH]

Scusate se tardo a ringraziare ma volevo provare ADO.
Effettivamente con ADO non ho problemi eccetto quello di modificare tutte le letture del software, diciamo 2 giorni di lavoro e non ancora ho finito, penso ancora uno e sono pronto.

Grazie a tutti per i consigli dati ma soprattutto a "gibra" per la spiegazione in dettaglio.

Adesso mi trovo ad affrontare un problema che sembra quasi stupido, ma ci sta...in relazione alla modifica che sto facendo;
in pratica la lettura del database con valori "Si No" insomma dove ci sono le spunte, tramite vb6 facevo un'operazione di confronto su label che leggevano il database (DAO), se la spunta esisteva il valore era "-1" altrimenti "0".
Con ADO il valore letto è "Vero" e "Falso" in italiano, se compilo il progetto in .exe diventa in inglese "True" e "False" questi valori non sono booleani ma stringhe, quindi facendo delle operazioni di confronto diventa un problema (in pratica se confronto in italiano funziona in test, se confronto in inglese funziona con l'eseguibile) e diventa antipatica la soluzione del tipo: if Variabile="True" or Variabile="Vero" then ......
Vi è mai capitato? sapete se è possibile ricavare un valore unico in lettura o cambiare lingua vb6? Insomma qualsiasi soluzione tranne OR...
Grazie ancora

[optime]

io di solito per evitare problemi faccio il confronto sempre con 0 (che vale come False). Se però ti ritorna una stringa e vuoi fare confronti, creati due variabili stringa (myTrue, myFalse) che inizializzerai prendendoli da un file di configurazione. Se cambi la lingua, ti basterà modificare il file di config

[gibra]

Adesso mi trovo ad affrontare un problema che sembra quasi stupido, ma ci sta...in relazione alla modifica che sto facendo;
in pratica la lettura del database con valori "Si No" insomma dove ci sono le spunte, tramite vb6 facevo un'operazione di confronto su label che leggevano il database (DAO), se la spunta esisteva il valore era "-1" altrimenti "0".
Con ADO il valore letto è "Vero" e "Falso" in italiano, se compilo il progetto in .exe diventa in inglese "True" e "False" questi valori non sono booleani ma stringhe, quindi facendo delle operazioni di confronto diventa un problema (in pratica se confronto in italiano funziona in test, se confronto in inglese funziona con l'eseguibile) e diventa antipatica la soluzione del tipo: if Variabile="True" or Variabile="Vero" then ......
Vi è mai capitato? sapete se è possibile ricavare un valore unico in lettura o cambiare lingua vb6? Insomma qualsiasi soluzione tranne OR...
Grazie ancora

Spiegati meglio, perché mi sa che stai facendo un po' di confusione.

I valori presenti in un campo di una tabella NON CAMBIANO a seconda del linguaggio o dalla tecnologia di accesso ai dati utilizzata.
Un campo di tipo booleano ha valori -1 o 0, qualsiasi sia la tencologia che usi.

Questa non è un'opinione, è un fatto, e non è in discussione.

Non capisco cosa c'entrino le Label... Le Label NON LEGGONO un database (e caso mai fosse così, 'leggerebbero' un campo), DAO non è un database, come non lo è ADO.

Il problema che lamenti io l'ho riscontrato solo nei file INI (quando leggi e/o scrivi), ed è per questo che io non uso mai i campi Bool ma sempre e solo di tipo numerico (0/1).

[LuigiDH]

Mi spiego, poichè mi sto adattando al lavoro fatto con DAO dove avevo delle label che catturavano i dati del database, adesso mi ritrovo comunque a dover caricare le stesse label ma con ADO.
Le check dei database acquisite in una label in lettura rispondono con valori VERO E FALSO mi sono accorto di questo dopo aver riscontrato delle anomalie di funzionamento, quindi con una msgbox ho letto i valori in fase di caricamento.