Discussion :

[PocoYote]

En tous cas, c'est la solution la plus propre pour le moment, car ne nécessite pas d'intervention de l'utilisateur.
Son seul défaut est que l'utilisateur doit se reconnecter ou redémarrer le logiciel. (mais ce sera le cas généralement).

Sous FB3, j'ai rapidement regardé les modifications, et j'ai lu que certaines tables n'étaient plus modifiables...
Mais bon le plus simple est de faire le test. Mais pour l'instant je reste sous FB2.5, je vais encore attendre un peu.

[TryExceptEnd]

Bonjour,
une autre solution à étudier : faire les mises à jour via une procédure (si c'est possible)
je n'aime pas trop ça,car j'estime qu'il ne faut pas en abuser (ça peut vite devenir un gros foutoir , j'ai eu une maintenance à faire de ce genre, pas facile trop de paramètres, trop de procédures appelant d'autres procédures << pas bon, pas de rollback possible )
mais une procédure = une transaction bien encapsulée
le problème reste le retour d'information (mais la procédure peut très bien retourner quelque chose )

je suis en train de préparer quelque chose de ce genre, le résultat dans un ou deux mois d'exploitation

Oui c'est possible de mettre toutes tes requêtes sur le serveur sous forme de PS avec des transactions autonomes, mais ce n'est pas franchement leurs rôle et je ne parle pas des limitations que ça induit.
En plus, les transactions lancé par l'applicatif resterons en suspend et vont encombrer le serveur a la longue.

[TryExceptEnd]

En tous cas, c'est la solution la plus propre pour le moment, car ne nécessite pas d'intervention de l'utilisateur.
Son seul défaut est que l'utilisateur doit se reconnecter ou redémarrer le logiciel. (mais ce sera le cas généralement).

Lorsqu'on a une déconnexion, il auras forcement une reconnexion... alors ou est le défaut ?

Sous FB3, j'ai rapidement regardé les modifications, et j'ai lu que certaines tables n'étaient plus modifiables...
Mais bon le plus simple est de faire le test. Mais pour l'instant je reste sous FB2.5, je vais encore attendre un peu.

Ne pas confondre les tables systèmes RDB$ et les tables de monitoring MON$.

[PocoYote]

Lorsqu'on a une déconnexion, il auras forcement une reconnexion... alors ou est le défaut ?

Le cas où le Wifi est planté et l'utilisateur éteint son PC pour en prendre un autre.

[Artemus24]

Salut

J'ai rien repris de ton idée, tu parlait de tâche et une tâche est soit un service ou une application, or il s'agit d'une connexion interne au serveur.

J'ai pris le sens du mot tâche (le thread en anglais) dans celui qui correspond à un traitement (cela peut-être n'importe quoi derrière, un service, une application ...) qui s'exécute en arrière plan sur le serveur.
Pour débloquer la situation, il suffit de la supprimer, et c'est ce que tu as donné comme solution, en détaillant la façon de le faire.
C'est ce que l'on nomme aussi un daemon dans le sens Unix.

Ce n'est pas la perte de la connexion (la cause) qui bloque, mais le fait que ce daemon (la conséquence) a planté !

Comme je l'ai déjà explique, il s’agit d'un verrou mis par firebird sur une ligne et que la perte de la connexion rend inaccessible et du coup impossible de lever ce verrou.

Oui, j'ai bien compris le problème.
Mais le blocage est dû à ce daemon qui continue à s'exécuter, tout en bloquant les dernières transactions.
Supprimer le daemon va débloquer la situation !

Troisièmement, prévoir une sortie de secours, comme la déconnexion "sauvage" laisse la connexion crée par votre application en suspend et bloque les lignes "updatés", le seul moyen de "finir" cette connexion est de la "tuer".

S'il s'agit de cela, nous sommes bien d'accord sur la solution à envisager, à savoir tuer ce daemon qui bloque les lignes.

La perte de connexion est facile à détecter et la reconnexion doit se faire automatiquement sans redémarrer l'application et sans intervention humaine et s'il n'y avait pas de blocage la requête "delete" aura le mérite de faire le nettoyage coté serveur.

Selon moi, la seule chose à faire est cette intervention manuelle.

Que voulez-vous faire au niveau application ? A vrai dire, je n'ai pas compris ce que vous désirez faire ?

@+

[vanquish]

L'article en lien ci-dessous, semble exactement décrire le problème :
https://www.ibphoenix.com/resources/...how_to/doc_104

Extrait :

It is important to promptly release the resources busy with such phantom connections, especially when using servers with Classic architecture. If some users connect to the server through an unstable modem connection, then the risk of disconnection becomes rather high.

For instance, a client saves a modified record set, and after UPDATE is executed (while COMMIT is not) the connection is released.

As a rule, client applications in such situations reconnect to the server, but the client (as he/she continues working with the data, after saving which one received error message due to connection fail) will be unable to save changes, since he/she will receive a message about lockout conflict (”lock conflict on update”). The previous connection, which opened the transaction (in the context of which UPDATE was executed, while COMMIT wasn’t), still holds these records.

Mais l'article semble expliquer comment Firebird évite que cela arrive - alors que visiblement ce n'est pas le cas.

[Artemus24]

Merci vanquish pour le lien.

[vanquish]

Après une lecture un peu plus approfondie, il y a dans firebird.conf un paramètre : DummyPacketInterval

Ce paramètre sert à dire au bout de combien de temps, le serveur va s'inquiéter du silence d'un client et lui envoyer un "packet" pour voir s'il est toujours là.
Par défaut c'est 2H.

Soucis, les remarques du fichiers firebird.conf indique : DO NOT USE THIS OPTION
Dommage

En gros ça peut faire crasher les clients Windows (visiblement windows lui même).
Mais quand on regarde les KB Microsoft cités en référence, cela semble surtout lié à de vieilles versions de Windows 2000.

Voir les autres infos dans firebird.conf au niveau de cette variable pour plus de détails.