Problèmes récurent de remontes (Erreur 132-2-42)

[ProulxS]

Bonjour,

Depuis fin février 2017 nous avons de gros problèmes avec nos remontes. Ils plantent toujours au début de "Traces Carte-Cadeau/Fidélisation: Vérification des traces..."
File error: 132
Procedure: 2
Sub proc: 42
C'est immanquable, ça plante à ce niveau, on résume et le remonte termine. Le remonte semble efficace parce que les rapports vont mieux après.

Acomba disent que le problème n'est pas de leur côté parce que lorsqu'on met les fichiers de la compagnie sur le même ordinateur qu'Acomba tout fonctionne. Selon eux il s'agit d'un problème réseau ou d'autorisation d'accès avec notre serveur (Business server 2011)
Notre service technique dis que tous fonctionne bien, les exclusions anti-virus sont bien faites, les autorisations de partages autorise tout le monde...

Présentement;
Compagnie sur serveur, acomba sur serveur = Remonte OK
Compagnie sur serveur, acomba distant = Remonte plante
Compagnie sur un ordinateur du domaine, Acomba sur un ordinateur différent = Remonte OK
Compagnie sur un ordinatinateur, Acomba sur le même ordinateur = Remonte OK

Tout pointe vers un problème avec le serveur mais personne ne semble savoir comment régler.
Nous avons essayé de refaire mise à jour acomba, rien à faire.
Nous avons essayé de désactiver l'antivirus, nope.
Nous avons fais les mises à jour sur le serveur, toujours pas.
Lorsqu'on ralenti la connexion internet (en se connectant via wifi), ça marche.  
Lors d'un remonte, le fichier de facturation est réindexé suivi des paiement client puis les traces carte-cadeaux... Notre théorie est que le fichier de facturation n'est pas fini d'écrire lorsque les traces carte-cadeaux arrive et essai de lire le même fichier causant notre erreur...

Help! Est-ce que quelqu'un a un problème similaire ou une idée de test pour arriver à une solution?

P.S.: Ordinateurs sous windows 7 x64
Serveur: Windows SmallBusiness Server 2011 sp1 (2008 R2 repacked)
Acomba Construction v9.90
Connecté via switch HP neuves (changé en décembre pour instabilité sur le réseau, et on a réessayé de changer en fin mars mais ce n'est pas la source du nouveau problème)

[PlanteG]

Bonjour,

ah les fameuses erreurs dans Acomba .

Partant du principe que le numéro d'erreur provient de Windows, j'ai trouvé ceci:

Error Code 132: The file pointer cannot be set on the specified device or file. [ERROR_SEEK_ON_DEVICE (0x84)]

trouvé à https://www.lifewire.com/system-error-codes-list-2625170 Confirmé sur le site de Microsoft [url=https://msdn.microsoft.com/en-us/library/windows/desktop/ms681382(v=vs.85).aspx[/url]

Ça ressemble à un problème de disque, comme une entrée de répertoire ou un secteur défectueux, mais vous dites que si la société est sur le serveur et acomba sur un poste distant, il y a un problème. Est-ce vrai dans cette configuration de tout ordinateur distant ?

[ProulxS]

Aucun des 4 ordinateurs sur lesquels j'ai tenté un remonte ne réussit lorsqu'Acomba est sur l'ordinateur et la compagnie sur le serveur.

Je ne crois plus qu'un secteur défectueux puisse être en cause puisque depuis le début du problème (mi/fin février) nous avons copier la compagnie de plusieurs sources et ce vers plusieurs destinations. Nous avons récupéré des backups via le serveur (et ce de différente sources d'archivage (RAID, QNAP et ARCSERVE je me perds un peu ici mais je sais que la source est différente) et également via une copie sur disque dûr externe lors de la procédure de fin d'année de la paie (avant le problème)....

Si effectivement Acomba ne réussit pas à verrouiller le file pointer sur le fichier ça confirmerait que l'un des fichiers devient verrouillé durant le remonte... Donc un file indexer, antivirus, programme de sauvegarde ou je sais pas quoi qui prend une photo du fichier immédiatement après sa création. Right?

Sur une de mes compagnies tests j'ai supprimé dix milles soumissions (2000 à 2008) au coût de 6 heures avant que je force l'arrêt d'Acomba et cette compagnie fonctionne maintenant... Malheureusement ce n'est pas un fix acceptable et même si nous l'acception il faudrait changer la date d'expiration de 32'000 soumissions dans les fichiers de la vrai compagnie. Est-ce possible de faire ça en batch?
:ugh:

[PlanteG]

Mouais,

voilà un vlimeux de problème.

Donc un file indexer, antivirus, programme de sauvegarde ou je sais pas quoi qui prend une photo du fichier immédiatement après sa création.

À ajouter à la liste le système de version précédente de Windows. Ce peut-il que ce soit cela ? Comme ça intervient quand on prend un point de restauration, les possibilités que cela arrive sont faibles.

La seule conclusion que l'on peut retirer de vos scénarios de test est que le problème ne se produit que si la société est sur le serveur avec un accès à distance. Comme le remonte ne peut être fait que si une seule personne est connectée à la société, ce n'est pas un problème d'accès bloqué.

En fait il y a deux problèmes:

• le fait que le remonte fonctionne mal
  
• qu'un problème force à faire un remonte
  

Avez-vous travaillé sur le deuxième ?

Peut-être les logs de Windows contiendront un piste .

[ProulxS]

Un bon remonte ça remet les idées en places... Nous travaillons avec des soumissions allant d'une 40aine de lignes de texte avec 3-4 items facturables à des soumissions de 400 lignes avec 250 item facturables donc nous avons parfois des ralentissements lorsque vient le temps d'enregistrer une telle soumission (et avec raisons). Comme ces soumissions prennent plusieurs heures à calculer les enregistrements sont fréquent en cours...

Plusieurs rapports sont également plutôt long à sortir (Âge des comptes par exemple) aussi, et ce depuis plusieurs années, un remonte est fait avant la fermeture de chaque module (3/fois par mois, client/fournisseur/compta). Et notre procédure inclut de faire un deuxième remonte après le premier remonte efficace. Normalement le deuxième remonte ne prends que quelques minutes puisque tout est déjà dans l'ordre...

Acomba m'ont suggèrer d'effacer les fichiers Crap, Frap et/ou Grap avant de faire mes rapports afin d'en accélérer la vitesse mais c'est pas l'idéal et j'ai parfois des erreurs quand je supprime le fichier pendant que la société est ouverte... Donc j’évite.

Tu dis que seule une personne est connectée à la société, mais je doute qu'Acomba verrouille tous les fichiers inclus dans la société... Selon moi ils bloquent uniquement la porte d'accès via l'interface d'Acomba. Un antivirus (ou autre) pourrais certainement tenter de lire un fichier présentement pas utilisé par Acomba au risque de collision lorsqu'Acomba est rendu à ce fichier...

[PlanteG]

À bien y penser, je crois qu'Acomba n'exige pas qu'une seule personne soit connecté pendant le Remonte .

Donc peut-être effectivement que c'est un problème réseau. Et ça va être difficile de trouver l'explication. Le * hum hum * système de base de données d'Acomba date d'un autre age: tous les clients doivent ouvrir les fichiers. On est loin du serveur qui sérialise les accès. Et en plus vous avez des grosses transactions dans le système. Dommage qu'Acomba X, basé sur SQL Server ne soit pas plus fiable/stable.

J'ai l'impression que la seule solution qu'il vous reste est d'effectuer le Remonte directement sur le serveur. Ce pourrait être à partir d'une session TS.

[ProulxS]

Oui oui vous avez raisons de dire qu'Acomba exige qu'une seule personne soit connecté. Il refuse de partir si deux usagés sont connectés à la société et indique que le fichier est en cours de récupération si quelqu'un essai de se connecter à la société durant un remonte...

MAIS ça c'est uniquement via la vrai ouverture de société... Un programme accèderais directement au fichier sans passer via Acomba.
Acomba X n'est tout simplement pas disponible en version Construction présentement avec la paie CCQ si je ne m'abuse.

Si je dois vraiment faire un remonte fonctionnel je peux effectivement me connecter sur le serveur et lancer construction à l'intérieur du serveur... Mais si quelque chose plante c'est tout le réseau qui devra être réinitialisé... Please god no.
Une autre option qui m'amuse toujours est d'arrêter mon remonte après la ligne Facturation (pendant Paiement client) avant qu'il ne commence Traces Carte-Cadeaux... Lorsqu'on résume le remonte il ne rencontre plus d'obstacle et ne frappe aucune erreur..... oh j'ai oublié de vous mentionner ce point auparavant.

C'est une des raisons pourquoi j'accuse la facturation. J'aurais dû le mentionner plus tôt mais en près de trois mois j'ai plein d'info sur ce problème et mes posts sont déjà si long :(

[Alex TR 61]

Bonjour

je me suis fait avec les années un catalogue de code d'erreur Acomba

Pour le 132-2-42 j'ai inscrit comme solutions : Éteindre le poste ou le serveur et réouvrir

Je pense que arrêté un remonte n'est pas une bonne idée

[ProulxS]

Les différentes postes utilisés au cours des nombreux remontes essayé au cours des deux derniers mois ont bien sûr été redémarré à plusieurs reprises...
Le serveur à été éteint à 3 différentes occasions. Sans succès il va sans dire.

Selon acomba un remonte interrompu puis repris aura les mêmes effets qu'on remonte accompli d'une traite. Il s'agit principalement d'une recréation d'index... Lors qu’interrompu un remonte recommence toujours un pas en arrière pour bien faire le point qu'il était en train de faire.

[Contenu sponsorisé]