zccmax
nel file .sql 2.4.53 prova a rimuovere completamente la riga/righe della query bloccante
che poi proverai e eseguire a db

Ho eseguito l'aggiornamento manuale sulle 2 tabelle "natura" e "cod_iva" seguendo quanto indicato nello script.sql della versione 2.4.14 ed è andato avanti ma si è fermato di nuovo sulla 2.4.16. per un errore di sintassi. Non penso che abbiamo rilasciato una versione con tanti problemi di installazione. Inizio a pensare che vi sia qualcosa di incompatibile. Sul server su cui devo fare la prova utilizzo MariaDB v. 10.11.

considera che i requisiti di OSM prevedono solo MySQL

Ciao, problema risolto. Probabilmente c'è qualche differenza fra MYSQL e MariaDB 10.11 nella gestione dei comandi SQL.
Sostanzialmente ho dovuto intervenire manualmente in svariati punti dell'aggiornamento delle tabelle, modificando i comandi ALTER TABLE dove venivano concatenate più operazioni di ADD.
Ho dovuto semplicemente separare queste operazioni per far riprendere l'aggiornamento.
Programma installato.

  • lucas ha risposto a questo messaggio

    Ciao, ho lo stesso problema avevo un backup fatto dove lavorava in MariaDB, ora sto cercando di passare a mysql, ma non riesco ad andare avanti, si blocca nell'aggiornamento db.
    Sapete se per caso devo convertire/modificare il database da mariadb a mysql prima di importarlo?

    Ciao plumino, mi spiace ma non so rispondere alla tua domanda. Io non uso MYSQL ma MariaDB e nel mio caso sono intervenuto nelle istruzioni dei file di aggiornamento e l'aggiornamento è terminato correttamente.

      17 giorni dopo

      zccmax Ho anche io lo stesso problema... possibile che ci invii i file con le patch che hai utilizzato per installare OSM anche su MariaDB? Grazie.

      Stesso problema!! Possibile avere procedura passo passo per risolvere il problema? Grazie

      zccmax

      In caso volessi contribuire a migliorare il software puoi suggerire questa modifica al codice caricando una pull request sul progetto di OpenSTAManager: https://github.com/devcode-it/openstamanager/pulls
      Sarà valutata volentieri e nel caso venisse aggiunta al sorgente del gestionale sarai incluso tra i contributori: https://github.com/devcode-it/openstamanager/graphs/contributors

      La community sicuramente ringrazierà.
      Grazie mille.

      • zccmax ha risposto a questo messaggio

        zccmax

        Stesso problema!! Possibile avere procedura passo passo per risolvere il problema? Grazie

        • zccmax ha risposto a questo messaggio

          vedo che ci sono parecchie discussioni bloccate sullo stesso problema... possibile che un admin ci dia un'occhio?

          cigo76
          Ciao, la questione è abbastanza semplice, ma delicata e va seguita con attenzione. Quello che ho appurato (o quantomeno succede nella mia versione di maria db 10.11.7) è che in taluni casi in presenza di istruzione ALTER TABLE con operazioni concatenate si genera un errore SQL. A quel punto è necessario verificare il punto in cui si ferma dal log degli errori di installazione ed accedere al file di aggiornamento DB a cui fa riferimento. Da qui hai 2 strade o modifichi il file di aggiornamento o operi con PhpMyAdmin facendo eseguire l'istruzione incriminata (Previa correzione della stessa cioè separando le operazioni concatenate e riscriverle come singole mantenendo l'ordine con le quali sono riportate nell'istruzione concatenata). Nel caso in cui tu dovessi decidere di operare con PhpMyAdmin dovrai ricordarti di commentare l'istruzione che va in errore e salvare il file editato. Fatto questo (in tutti i 2 i casi) forza la ripartenza dell'installazione. Spero di essere stato abbastanza chiaro.

          lucas
          Ciao ci ho provato ... ma non ci sono riuscito. Ma la questione mi sembra molto semplice. Se potete quando preparate il pacchetto di aggiornamento del DB è meglio evitare istruzioni complesse di ALTER TABLE con molte operazioni di ADD. Questo è quanto ho appurato durante l'installazione su server dotato di MariaDB 10.11.7. Ho dovuto correggere svariati file di aggiornamento per poter continuare. Nel mio coso ho preferito eseguire le istruzioni SQL in MyPhpAdmin singolarmente e commentare le istruzioni nei file di aggiornamento. Spero possa essere di aiuto. Ciao.

          Ciao a tutti!
          Alla fine io ho risolto, anche se in modo diverso.
          L'installazione a me si bloccava sull'aggiornamento 2.4.14 .
          L'istruzione che andava in crash, preso dal log setup.log, era questa:

          Logs.EMERGENCY: Aggiornamento fallito: ALTER TABLEfe_naturaCHANGEcodicecodiceVARCHAR(5) NOT NULL []

          Se andavo a dare questa istruzione a mano sul phpmyadmin mi restituiva questo errore

          ALTER TABLE fe_natura CHANGE codice codice VARCHAR(5) NOT NULL;
          #1833 - Cannot change column 'codice': used in a foreign key constraint 'xxx/co_iva_ibfk_1' of table 'xxx/co_iva'

          Mi sembra di poter capire che non possa editare quel campo perché è una chiave esterna della tabella co_iva.
          Ho dato un'occhiata su internet per vedere se ci fosse il modo di sbloccare un campo foreign key, ma con le varie ricette trovate non sono riuscito nel mio intento.

          Visto che il mio impedimento era solo modificare quel campo da 2 a 5 caratteri, sono andato direttamente alla fonte, modificando il valore del campo sul file 2.4.2.sql e commentandolo poi sul file 2.4.14.sql.
          Installazione completata senza nessun problema.

          Spero che possa essere d'aiuto anche agli altri.

          Saluti.

          • cigo76 ha risposto a questo messaggio

            vassiskansa
            Potresti gentilmente indicarmi passo passo dove e come commentare ? Purtroppo non sono molto esperto in materia!! Grazie ancora

              cigo76 devi modificare la riga 157 del file update/2_4_2.sql così:

              codicevarchar(5) NOT NULL,

              e poi devi commentare la riga 368 del file update/2_4_14.sql così:

              --ALTER TABLEfe_naturaCHANGEcodicecodiceVARCHAR(5) NOT NULL;

              successivamente, nel mio caso, ho dovuto riavviare l'installazione da 0 cancellando tutto il DB.

              Saluti.

              • cigo76 ha risposto a questo messaggio

                vassiskansa
                Perfetto grazie mille!!
                n.b. Ma commentando la riga riga 368 perde le sue funzionalita'?

                  cigo76 non credo, perché il varchar(5) lo dichiari praticamente in fase di setup iniziale... non conosco bene il prodotto, ma credo che siano state fatte delle modifiche successive per adattare esigenze che non c'erano inizialmente... ma questo bisognerebbe chiederlo ai programmatori!

                  8 giorni dopo
                  Rispondi alla discussione...