Aggiornamento DB da 2.1 a 2.3

gippiesse

Salve, utilizzo da anni il Vs. pregiato SW ma non ho mai fatto aggiornamenti per via di una serie di piccole personalizzazioni che ho apportato nel tempo e che ho anche postato in questo Forum.

Oggi volevo finalmente provare ad evolvermi ed ho quindi scaricato da GitHub l'ultima versione mettendola in una dir apposita in /var/www/html/osm23.
In fase di configurazione l'ho fatto puntare al DB esistente e durante l'adeguamento dello stesso qualcosa va storto.
Per la precisione da 2.1 a 2.2 pare farlo correttamente, poi dà questo errore:
SQLSTATE[21000]: Cardinality violation: 1242 Subquery returns more than 1 row

Anzi, questo lo ricevo dopo un refresh della pagina che vedete in allegato.

C'è modo di trovare dove viene generato l'errore? Oppure voi sapete cosa potrebbe essere?

Grazie.

dasc3er

Ciao gippiesse,
Potresti allegare i file di log che trovi all'interno della cartella logs/?
In questo modo possiamo consigliarti come procedere...

gippiesse

Gli ho dato un'occhiata e credo che quello utile sia setup.log:

[2018-01-27 11:54:33] Logs.EMERGENCY: SQLSTATE[21000]: Cardinality violation: 1242 Subquery returns more than 1 row - Aggiornamento fallito: UPDATE `zz_files` SET `id_module` = (SELECT `id` FROM `zz_modules` WHERE `zz_modules`.`directory` = `zz_files`.`module`)
{"url":"/osm23b2/index.php?action=do_update&firstuse=false","ip":"::1","http_method":"GET","server":"localhost","referrer":"http://localhost/osm23b2/index.php","uid":"79979b8"} 
[2018-01-27 17:52:51] Logs.EMERGENCY: SQLSTATE[21000]: Cardinality violation: 1242 Subquery returns more than 1 row - Aggiornamento fallito: UPDATE `zz_files` SET `id_module` = (SELECT `id` FROM `zz_modules` WHERE `zz_modules`.`directory` = `zz_files`.`module`)
{"url":"/osm23b2/index.php?action=do_update&firstuse=false","ip":"::1","http_method":"GET","server":"localhost","referrer":"http://localhost/osm23b2/index.php","uid":"8c79248"}

Riportando la subquery in PHPmyAdmin dice:

#1054 - Unknown column 'zz_files.module' in 'where clause'

Ma magari così decontestualizzata ha pure ragione... Però è strano perché il campo module in zz_files esiste eccome.

Poi ho provato a modificarla così:

SELECT `zz_modules`.`id` FROM `zz_modules`,`zz_files` WHERE `zz_modules`.`directory` = `zz_files`.`module`;

e in effetti noto che tra i risultati ci sono due (gruppi di) valori differenti: 3 e 33.
La voce con ID 33 la creai io ed è un'altra visualizzazione degli interventi che però mostra solo quelli con lo stato "Completato" ed evidenzia quelli in cui ci sono merci consegnate.

A questo punto provo a rimuovere tale voce e rifarla con l'apposito editor che avete messo (se capisco come si fa :--).

gippiesse

Annoto qui il contenuto del campo 'options' di quel record:

{	"main_query": [	{	"type": "table", "fields": "ID intervento, Ragione sociale, Data inizio, Data fine, merci, _print_",	"query": "SELECT 
	`in_interventi`.`idanagrafica`, 
	`in_interventi`.`idintervento` AS `id`, 
	`in_interventi`.`idintervento` AS `ID intervento`, 
	`ragione_sociale` AS `Ragione sociale`, 
	MIN( DATE_FORMAT( `orario_inizio`, '%d/%m/%Y' ) ) AS `Data inizio`, 
	MAX( DATE_FORMAT( `orario_fine`, '%d/%m/%Y' ) ) AS `Data fine`, 
	`data_richiesta`, 
    `in_interventi`.`idstatointervento`, 
	(SELECT `colore` FROM `in_statiintervento` WHERE `idstatointervento`=`in_interventi`.`idstatointervento`) AS `_bg_`, 
	`mg_articoli_interventi`.`idintervento` as `merci`,
	'pdfgen.php?ptype=interventi&idintervento=$id$&mode=single' AS `_print_`, 
	`orario_inizio`, `orario_fine` 
FROM 
	(`in_interventi` INNER JOIN `an_anagrafiche` ON 
        `in_interventi`.`idanagrafica`=`an_anagrafiche`.`idanagrafica`) 
    LEFT OUTER JOIN `in_interventi_tecnici` ON 
        `in_interventi_tecnici`.`idintervento`=`in_interventi`.`idintervento`
	LEFT OUTER JOIN `mg_articoli_interventi` ON
		`in_interventi_tecnici`.`idintervento`=`mg_articoli_interventi`.`idintervento`
WHERE
        `in_interventi`.`idstatointervento` = 'OK'
GROUP BY 
        `in_interventi`.`idintervento` 
HAVING 
    1=1 AND 
    ( ( DATE_FORMAT( `orario_inizio`, '%Y-%m-%d' ) >= '|period_start|' AND 
    DATE_FORMAT( `orario_fine`, '%Y-%m-%d' ) = '|period_start|' AND 
    DATE_FORMAT( `data_richiesta`, '%Y-%m-%d' )

gippiesse

Vi confermo che eliminando il record che avevo inserito io la migrazione del DB va a buon fine.

Grazie per la pazienza e grazie per lo spunto 🙂

Ora, però... DOVE SONO FINITI I LOTTI?!?
Io li usavo (impropriamente) al posto dei S/N, ma non ne vedo più traccia 🙁

dasc3er

Effettivamente, con la versione 2.3 i lotti sono stati disabilitati in favore di una migliore gestione dei serial number...
Puoi passare dai lotti ai serial number (e ripristinare i valori precedenti) utilizzando la seguente query:

UPDATE `mg_prodotti` SET `serial` = `lotto` WHERE `lotto` IS NOT NULL;

Questa query sovrascrive in modo completo i serial number presenti, quindi evita di usarla se hai utilizzato anche i serial number insieme ai lotti.