Base régulièrement corrompue: recherche cause

[surfer2k]

Bonjour,
Nous avons une application en Delphi 7 assez volumineuse qui accède à une base interbase en local.

Le serveur utilisé pour l'instant est Interbase 6.0.2 et malheureusement je ne peux pas envisager un passage sur Firebird pour l'instant.

J'ai déjà fait toutes les vérifications et paramétrages du serveur et de la base que j'ai pu trouvez de ci et de là.

Mon problème se situe sur la corruption régulière de la base.
Ainsi à chaque fois que la base est corrigée, 1 à 2 semaines après il faut le refaire.

Je cherche un moyen d'identifier ce qui cause ce problème (log au niveau de Delphi mais au vu du nombre de requête celà me semble enorme, log au niveau du serveur, faire une vérification de la base après chaque option de menu mais là l'utilisateur va criser, ...).

Donc si quelqu'un a une suggestion ou a deja connu ce problème, je suis preneur car il faut que je trouve pourquoi cela se produit.

Merci d'avance à vous tous

[makowski]

Avec Interbase 6.0.2 les causes de corruptions de données sont quasi inévitables

Firebird 1.0.3 est un Interbase 6.0 debuggué qui devrait éviter un bon nombre de ces problèmes et ils sont tous les deux parfaitement interchangeables.

[surfer2k]

Bon je vais donc regarder de ce coté mais si je dois installer Firebird 1.0.3 autant m'orienter vers la 2.0 directement !

Merci

[surfer2k]

Bonjour,

Après quelques tests, il s'avère que je ne peux pas simplement installer FireBird 1 en remplacement d'Interbase. Ainsi le code SQL a été écrit par différentes personnes et les jointures ne sont pas toujours pré-fixées par le nom de la table.
Resultat: là où avec IB 6 j'ai l'affichage des données, avec Fb 1 j'ai un message d'erreur.

Je sais que c'est une erreur de code mais je ne peux pas me permettre de passer en revue l'ensemble de l'application dans l'immédiat.

Est-ce qu'un paramétre de FB 1.0 permet de désactiver cette vérification ?

Merci pour votre aide

[makowski]

Firebird 1.0.3 ???
non je ne crois pas que tu puisses avoir des problèmes de ce genre, tu dois parler d'une autre version (2.0 par exemple, là oui tu peux avoir ces problèmes, mais qui normalement sont résolus avec le paramêtre OldColumnNaming de firebird.conf et le paramètre RelaxedAliasChecking disponible dans la 2.1 (actuellement en RC1) et la 2.0.4 (pas sortie encore))

[surfer2k]

Bonjour,
Non il s'agit bien de la 1.5.3. Je vais essayer avec les paramètres indiqués.
J'ai effectivement des requêtes avec un mélange d'utilisation entre le nom de la table et de l'alias ou encore des champs de même nom sans prefixe.

D'après ce que j'ai lu ces vérifications sont désactivées si on est en dialect 1 ce qui m'oblige à faire un backup restaure.

Ou est-ce que je peux trouver une liste complète des paramétres de firebird.conf ?

Merci

[comico]

Salut

Je crois que Philippe t'orientait sur la 1.0.3 pour être le plus proche possible d'Interbase 6, pas la 1.5.3 !

[makowski]

Envoyé par surfer2k

Non il s'agit bien de la 1.5.3.

GRRR !
et moi je te dis 1.0.3 !

[surfer2k]

Bonjour
Non il s'agit bien de la 1.0.3 (fichier d'installation Firebird-1.0.3.972-Win32.exe). j'ai bien suivi les conseils par contre si on regarde la doc:

Ambiguous JOIN statements are now rejected
InterBase does not prevent you from submitting a statement like this:
SELECT A.FIELDA, B.FIELDA
FROM A JOIN B
ON FIELDX = FIELDY
WHERE FIELDA="99"
ORDER BY FIELDA
Such statements return unpredictable output sets. Now Firebird, in Dialect 3, will return an error if
there are any unqualified column identifiers in join statements. In Dialect 1, it will return a warning
but the ambiguous query will be allowed to proceed.

Cela signifie bien que je dois faire un backup restaure pour avoir une base en dialect 1 qui fonctionnera comme IB 6.0x ?

Merci

[makowski]

Envoyé par surfer2k

Cela signifie bien que je dois faire un backup restaure pour avoir une base en dialect 1 qui fonctionnera comme IB 6.0x ?

Si ta base était en IB6 Dialect1 oui
sinon, perdu, il faut réécrire correctement les requêtes