arghami ha scritto: ↑02 ago 2017, 14:27
Trova il path completo che ti porta all'installazione di Java7 (supponiamo sia C:\Program Files (x86)\Java\jre7). Fatto questo la modifica che devi fare è:
"C:\Program Files (x86)\Java\jre7\bin\java.exe" -cp %classpath% -jar confrontiStorici.jar %1 %2 %3
Funziona!!! Mi stendo ai tuoi piedi e mi faccio calpestare come uno zerbino
Avevo fatto anche quella prova ma quello che dimenticavo di mettere erano i doppi apici al percorso di java quindi l'istruzione non veniva letta correttamente.
Generato tutto perfettamente e con i dati corretti.
Ottimo!!!
Adesso preparo un altro topic spiegando come fare punto per punto.
Se Confronti Storici non vi funziona più in fase di generazione il problema è la versione di Java.
Per risolvere installate una versione datata, io ad esempio ho utilizzato la 1.7
N.B. Tutte le versioni di java precedenti l'ultima sono presenti sul sito istituzionale, per il download occorre registrarsi gratuitamente.
Non occorre rimuovere la versione che avete già installato, si aggiungerà in un nuova cartella.
Ora avete due versioni di java sul pc, quella più recente e quella datata che avete installato.
Le applicazioni, di default, utilizzeranno sempre l'ultima versione a meno che non gli si dica altrimenti.
Ed è quello che bisogna invece fare con Confronti Storici, forzarlo ad usare la vecchia versione di java.
Aprite con il blocco note il file confrontiStorici.bat che trovate nella cartella plugin di FCM Si presenta così:
@echo off
set classpath=.
cd C:\Program Files (x86)\FCM\plugin
rem ======================= CONFIGURAZIONE 1 ================================
java -cp %classpath% -jar confrontiStorici.jar %1 %2 %3
rem =========================================================================
rem ======================= CONFIGURAZIONE 2 ================================
rem java.exe -cp %classpath% -jar confrontiStorici.jar %1 %2 %3
rem =========================================================================
rem ======================= CONFIGURAZIONE 3 ================================
rem C:\Windows\SysWOW64\java.exe -cp %classpath% -jar confrontiStorici.jar %1 %2 %3
rem =========================================================================
La configurazione 1 va modificata così:
rem ======================= CONFIGURAZIONE 1 ================================ "C:\Program Files (x86)\Java\jre7\bin\java.exe" -cp %classpath% -jar confrontiStorici.jar %1 %2 %3
rem =========================================================================
Quello tra i doppi apici è il mio percorso, verificate il vostro.
Salvate e andate nel file .ini della vostra skin, che si trova nella cartella skin di FCM, apritelo sempre con blocco note e andate alla fine.
Dovreste trovare confrontiStorici31.exe, sostituitelo con confrontiStorici.bat
Salvate.
La prossima generazione dovrebbe funzionare correttamente.
N.B. Se al successivo aggiornamento di Java dovesse chiedervi di rimuovere versioni obsolete rispondete ovviamente di no.
Ringrazio ancora Arghami per la dritta risolutiva.
Ultima modifica di Dragobono il 03 ago 2017, 09:37, modificato 2 volte in totale.
lukesky ha scritto: ↑02 ago 2017, 12:59
In ConfrontiStorici (e anche in se avessi avuto .... dopo che Arghami ha pubblicato i sorgenti ) per ovviare al problema del Java 8 e dei driver ODBC su ACCESS a 64 bit, ho introdotto dei driver che si chiamano UCANACCES che risolvono il problema, pur rallentando le elaborazione.
Il problema è che il DB di FCM all'interno contiene l'archivio giocatori (che ConfrontiStorici legge), e in alcuni casi nell'archivio ci sono degli errori che con il driver di windows venivano bypassati, con UCANACCESS invece interrompono l'elaborazione.
Per risolvere di solito basta fare un COMPATTADB da FCM, oppure modificare l'archivio giocatori inserendo un giocatore nuovo e poi cancellandolo, ma dove non è possibile occorre intervenire manulmente sul database (una volta trovato il problema).
A questo punto mi viene una curiosità: stai gestendo entrambi i driver? Cioè provi a caricare il driver access odbc e nel catch carichi il ucanaccess? Perché altrimenti non mi spiego quello che succede switchando tra java 7 e 8.
lukesky ha scritto: ↑02 ago 2017, 12:59
In ConfrontiStorici (e anche in se avessi avuto .... dopo che Arghami ha pubblicato i sorgenti ) per ovviare al problema del Java 8 e dei driver ODBC su ACCESS a 64 bit, ho introdotto dei driver che si chiamano UCANACCES che risolvono il problema, pur rallentando le elaborazione.
Il problema è che il DB di FCM all'interno contiene l'archivio giocatori (che ConfrontiStorici legge), e in alcuni casi nell'archivio ci sono degli errori che con il driver di windows venivano bypassati, con UCANACCESS invece interrompono l'elaborazione.
Per risolvere di solito basta fare un COMPATTADB da FCM, oppure modificare l'archivio giocatori inserendo un giocatore nuovo e poi cancellandolo, ma dove non è possibile occorre intervenire manulmente sul database (una volta trovato il problema).
A questo punto mi viene una curiosità: stai gestendo entrambi i driver? Cioè provi a caricare il driver access odbc e nel catch carichi il ucanaccess? Perché altrimenti non mi spiego quello che succede switchando tra java 7 e 8.
Esatto, uso i driver a seconda della versione Java e del sistema operativo ! Non li carico entrambi, scelgo al momento dell'esecuzione. Ucanaccess è molto più lento e quindi non volevo penalizzare chi ha vecchie versioni (che di logica già è penalizzato dall'età del Pc).
lukesky ha scritto: ↑02 ago 2017, 12:59
In ConfrontiStorici (e anche in se avessi avuto .... dopo che Arghami ha pubblicato i sorgenti ) per ovviare al problema del Java 8 e dei driver ODBC su ACCESS a 64 bit, ho introdotto dei driver che si chiamano UCANACCES che risolvono il problema, pur rallentando le elaborazione.
Il problema è che il DB di FCM all'interno contiene l'archivio giocatori (che ConfrontiStorici legge), e in alcuni casi nell'archivio ci sono degli errori che con il driver di windows venivano bypassati, con UCANACCESS invece interrompono l'elaborazione.
Per risolvere di solito basta fare un COMPATTADB da FCM, oppure modificare l'archivio giocatori inserendo un giocatore nuovo e poi cancellandolo, ma dove non è possibile occorre intervenire manulmente sul database (una volta trovato il problema).
Ho avuto anche io problemi con la versione aggiornata di Java, sto procedendo alle modifiche suggerite.
Però volevo segnalare che SE si fa il Compatta DB con il nuovo anno (e il nuovo archivio...) dice
"NON è stato possibile compattare l'archvio probabilmente per mancanza di spazio sul disco. Questo non pregiudica il normale funzionamento del programma. Errore 0"
lukesky ha scritto: ↑02 ago 2017, 12:59
In ConfrontiStorici (e anche in se avessi avuto .... dopo che Arghami ha pubblicato i sorgenti ) per ovviare al problema del Java 8 e dei driver ODBC su ACCESS a 64 bit, ho introdotto dei driver che si chiamano UCANACCES che risolvono il problema, pur rallentando le elaborazione.
Il problema è che il DB di FCM all'interno contiene l'archivio giocatori (che ConfrontiStorici legge), e in alcuni casi nell'archivio ci sono degli errori che con il driver di windows venivano bypassati, con UCANACCESS invece interrompono l'elaborazione.
Per risolvere di solito basta fare un COMPATTADB da FCM, oppure modificare l'archivio giocatori inserendo un giocatore nuovo e poi cancellandolo, ma dove non è possibile occorre intervenire manulmente sul database (una volta trovato il problema).
Ho avuto anche io problemi con la versione aggiornata di Java, sto procedendo alle modifiche suggerite.
Però volevo segnalare che SE si fa il Compatta DB con il nuovo anno (e il nuovo archivio...) dice
"NON è stato possibile compattare l'archvio probabilmente per mancanza di spazio sul disco. Questo non pregiudica il normale funzionamento del programma. Errore 0"
lukesky ha scritto: ↑02 ago 2017, 12:59
In ConfrontiStorici (e anche in se avessi avuto .... dopo che Arghami ha pubblicato i sorgenti ) per ovviare al problema del Java 8 e dei driver ODBC su ACCESS a 64 bit, ho introdotto dei driver che si chiamano UCANACCES che risolvono il problema, pur rallentando le elaborazione.
Il problema è che il DB di FCM all'interno contiene l'archivio giocatori (che ConfrontiStorici legge), e in alcuni casi nell'archivio ci sono degli errori che con il driver di windows venivano bypassati, con UCANACCESS invece interrompono l'elaborazione.
Per risolvere di solito basta fare un COMPATTADB da FCM, oppure modificare l'archivio giocatori inserendo un giocatore nuovo e poi cancellandolo, ma dove non è possibile occorre intervenire manulmente sul database (una volta trovato il problema).
Ho avuto anche io problemi con la versione aggiornata di Java, sto procedendo alle modifiche suggerite.
Però volevo segnalare che SE si fa il Compatta DB con il nuovo anno (e il nuovo archivio...) dice
"NON è stato possibile compattare l'archvio probabilmente per mancanza di spazio sul disco. Questo non pregiudica il normale funzionamento del programma. Errore 0"
Ho avuto anche io problemi con la versione aggiornata di Java, sto procedendo alle modifiche suggerite.
Però volevo segnalare che SE si fa il Compatta DB con il nuovo anno (e il nuovo archivio...) dice
"NON è stato possibile compattare l'archvio probabilmente per mancanza di spazio sul disco. Questo non pregiudica il normale funzionamento del programma. Errore 0"
Da cosa dipende?
Secondo me ci sono problemi sull'archivio.
eh vai a capire dove....@Rainbow?
Sul mio non ho problemi. Vuoi provare a mandarmi un export Lega ?
Grazie Lù, ma devo isolare il problema. Perchè anche se faccio il calendario mi da lo stesso errore 0....
UHM....ieri ho aggiornato il sito ad un amico senza problemi....e il mio non funge....Uhm....classico esempio di scarparo con le scarpe rotte
ti faccio sapere
) per ovviare al problema del Java 8 e dei driver ODBC su ACCESS a 64 bit, ho introdotto dei driver che si chiamano UCANACCES che risolvono il problema, pur rallentando le elaborazione.
