Discussion :

[chekkal]

Bonjour à tous,

Avant de travailler avec firebird, j'utilisé interbase 7.1 et j'ai constaté que on forçant un peu sur la base de données (beaucoup d'accée dans un temps minim) la base de données plantée et même peut devenir inutilisable. Et je voudrais savoir si ça peut arriver avec firebird et qu'elles sont les commandes sql à éviter d'utiliser souvent.

[SergioMaster]

Bonsoir,

pourtant Interbase est fiable je penche plutôt pour une mauvaise gestion des transactions. Ou encore, un cas qui m'est arrivé une surchauffe du processeur du serveur

[chekkal]

Je t'assure que ça m'es arrivé souvent, et pour te donner une méthode efficace pour détérioré ta base de données, il te suffit d'ouvrir une table de la base de données et insérer une ligne et avant validation coupé le courant et répétant cette opérations une ou 2 fois votre base de données interbase ne va pas résister, j'ai pas eu ce cas avec firebird, mais comme dit le proverbe "Vaut mieux prévenir que guérir"

[SergioMaster]

il te suffit d'ouvrir une table de la base de données et insérer une ligne et avant validation coupé le courant

Sauf qu'un programmeur sérieux n'ouvrirai pas une table entière pour faire une insertion et que cette dernière devrait être dans une transaction.
Au pire la transaction dans ce cas là serait en LIMBO . Sachant que Interbase (comme Firebird) fait des sweeps régulier et qu'une bonne staégie est de faire de régulier backups, la transaction en LIMBO serait vite oubliée.

Comme je l'ai déjà indiqué mon expérience avec le processeur en surchauffe (équivalent d'une coupure de courant) à certes plusieurs fois perturbé la base de données Interbase (à l'époque c'était 5.1 je crois) et donné quelques lenteur qu'un backup (sans même restore comme Firebird) réglait généralement
il ne m'est arrivé que 2 fois en 6 mois (avant d'enfin comprendre le pourquoi) d'avoir à faire des fixs.
Dire que Interbase n'est pas fiable (même ou surtout sur un forum Firebird), c'est un peu exagéré

[chekkal]

Bonjour,

J'ai jamais dit que interbase n'est pas fiable, j'ai exposé seulement un cas et ma question première été de savoir s'il ya des commandes à éviter d'utiliser souvent parce que il sollicite beaucoup la base de données.

Sauf qu'un programmeur sérieux n'ouvrirai pas une table entière pour faire une insertion

Là tu m'a vexé, comme je l'ai dit dans une précedente discussion c'est pas a l'utilisateur de s'adapter au choix du concepteur mais c'est le concepteur qui doit satisfaire la demande de l'utilisateur(client)

[cantador]

@chekkal

s'il ya des commandes à éviter d'utiliser souvent parce que il sollicite beaucoup la base de données.

Pour ma part, je n'en vois pas.
Firebird, c'est du costaud..

si ça coince quelque part, il faut se remettre en cause et dans 99% des cas, cela vient de la conception même du programme.
je garde 1% pour les trucs non résolus car c'est de l'open source.

cantador

[SergioMaster]

Bonjour

Là tu m'a vexé

désolé, je ne jetais aucune pierre car moi aussi j'ai péché (par pure facilité=paresse et par méconnaissance) au temps ou seul le BDE était proposé.
C'est l'expérience (maitre mot) qui me permet d'affirmer une telle chose

c'est pas a l'utilisateur de s'adapter au choix du concepteur mais c'est le concepteur qui doit satisfaire la demande de l'utilisateur

tout à fait d'accord mais le concepteur peut tricher : par exemple en affichant une table en lecture seule et utiliser une Query pour les Insertion/Update
c'est donc bien au concepteur d'adapter son code aux contraintes de l'utilisateur et de l'environnement (base de données , réseau, langage etc...)


je suis tout à fait d'accord avec la remarque de Cantador

il faut se remettre en cause et dans 99% des cas, cela vient de la conception

sauf que j'y mettrai du programme ou de la structure base de données

Bien sur on n'est pas à l'abri d'une panne, pour l'électricité c'est un faux problème il y a la solution : l'onduleur (à tout le moins pour le serveur)
pour le processeur (comme dans mon cas) là c'est plus difficile il s'agit de moyens . A l'époque on était encore en test et le poste n'était qu'un XP mis dans un coin trop poussiéreux (cause travaux : nouvelle usine ) et le réseau n'était pas encore très stable (câbles non blindé pour certains postes, grosses machines outils juste à coté provoquant des surtensions et/ou l'inverse etc...). Pour la petite histoire on avait demandé à l'architecte de faire poser du câble réseau , je me suis retrouver lors de ma première visite avec un cable de presque 2 cm de diamètre avec 9 fils en conséquence facile pour mettre une rj45 dessus et un cable BNC (qui lui m'a permis de faire tourner le réseau en étoile en attendant)
C'est d'ailleurs pour toutes ces raisons qu'il a été très difficile de trouver le vrai coupable . Programme, réseau, surtensions etc... il a fallu tout passer au crible

après investissement dans un bon serveur, un onduleur , une armoire réseau la correction des câbles et de la fibre pour les ateliers plus aucun soucis ! jusqu'à la création d'un dépôt éloigné de 10km et la nécessité de revoir la conception des programmes et remettre en cause(j'y suis parvenu) mes premiers programmes (1998) écrit avec BDE avec utilisation des Tables au lieu de Query etc... Même après la mise en place d'un réseau transpack les performances étaient lamentables
Delphi (et moi) ayant beaucoup évolué entre temps => ré-écriture des parties utilisées , abandon progressif de BDE mais aussi (pour limiter les frais de licence Interbase très cher à l'époque) passage à Firebird .

Pour information encore, lorsque après plus de 10 ans de bons et loyaux services on a décidé de changer de serveur, nous nous sommes adressés au même constructeur qui lui même a été surpris de sa longévité. Ce dernier que nous avons encore va bientôt lui aussi sur ses 10 ans

[Barbibulle]

Je t'assure que ça m'es arrivé souvent, et pour te donner une méthode efficace pour détérioré ta base de données, il te suffit d'ouvrir une table de la base de données et insérer une ligne et avant validation coupé le courant et répétant cette opérations une ou 2 fois votre base de données interbase ne va pas résister, j'ai pas eu ce cas avec firebird, mais comme dit le proverbe "Vaut mieux prévenir que guérir"

Je ne vois pas le rapport avec la question initiale ???

Il est évident qu'il faut éviter les coupures de courants et ca quelque soit la base de données. D'ailleurs si c'est quelque chose qui arrive trop souvent ce n'est pas le développeur qui doit apporter la solution mais un électricien... Notamment équiper le serveur / poste d'onduleur.