You are not logged in.
Pages: 1
Topic closed
Si jamais la synchronisation démarre en mode "réplicat" cela génrère pas mal de soucis
Ok, la base GLPI étant en lecture seule aucune mise à jour ne sera effectuée, cependant, OCS pourra être modifié.
En particulier lors du traitement de la table deleted_equiv
Extrait des logs :
10-09-2008 13:36: *** MySQL query error :
***
SQL: UPDATE glpi_ocs_link
SET ocs_id=\'239778\', ocs_deviceid=\'P561C161-2008-09-10-12-06-29\'
WHERE ocs_id=\'236739\' AND ocs_server_id=\'2\'
Error: UPDATE command denied to user 'toto'@'titi' for table 'glpi_ocs_link'
Backtrace :
/app/gbp02/web/glpi/inc/ocsng.function.php:370 DBmysql->query()
/app/gbp02/web/glpi/plugins/mass_ocs_import/scripts/ocsng_fullsync.php:225 ocsManageDeleted()
/app/gbp02/web/glpi/plugins/mass_ocs_import/scripts/ocsng_fullsync.php:91 FirstPass()
ocsng_fullsync.php
Bilan => au retour sur le serveur normal => génération de doublons.
Donc il faut prévoir un test en début de traitement.
Voir aussi si cela n'affecte pas le coeur.
A suivre..
P.S. encore un problème de riche qui bosse avec 3 serveurs MySQL différents
Dév. Fedora 29 - PHP 5.6/7.0/7.1/7.2/7.3/7.4 - MariaDB 10.3 - GLPI master
Certifié ITILv3 - RPM pour Fedora, RHEL et CentOS sur https://blog.remirepo.net/
Offline
Dév. Fedora 29 - PHP 5.6/7.0/7.1/7.2/7.3/7.4 - MariaDB 10.3 - GLPI master
Certifié ITILv3 - RPM pour Fedora, RHEL et CentOS sur https://blog.remirepo.net/
Offline
Pages: 1
Topic closed