Bonjour à tous,
FirBird 1.5
j'ai une table dont un champ est de type Blob subtype 0 et taille 30 Ko.
Comment puis-je inserer des images de taille plus que 200 Ko dans ma base ? à titre d'indication taille max autorisé par ibExpert est 32 Ko!
Version imprimable
Bonjour à tous,
FirBird 1.5
j'ai une table dont un champ est de type Blob subtype 0 et taille 30 Ko.
Comment puis-je inserer des images de taille plus que 200 Ko dans ma base ? à titre d'indication taille max autorisé par ibExpert est 32 Ko!
Ca veux dire quoi 30Ko ? On ne peut donner la taille d'un blob car par définition ils ont des contenus libres.Citation:
Envoyé par moucrack
Vous parlez peut etre de la taille du segment ?? Dans ce cas 30Ko c'est certainnement un peu trop, enfin faut voir avec le type de données que vous comptez enregistrer.
Avec IbExpert (version enregistré) il y a un editeur de BLOB.Citation:
Envoyé par moucrack
Sinon les BLOB se créent par programmation. Sous Delphi par exemple il suffit d'utliser les FIELDs pour pouvoir créer un blob de toute pièce ou encore charger à partir d'un fichier. Cf le forum concerné, par votre langage car la technique n'est pas spécifiques à Fb ou interbase.
Merci de spécifier quel version vous utilisez (La version free) ?Citation:
Envoyé par moucrack
La version enregistrée n'a pas de limite de taille concernant les BLOBs...
Merci infinement de me repondre sur ma question mais j'ai déjà résolu le pb en inserant directement dans le champ blob dont le subtype = 0 : binary et non de subtype text!.
Concernant le 32 Ko c'est la taille max du segment et c ne pas du BLOB! (désolé)
je profite cette occasion et je repose ma question qui a déjà posé mais sans aucune reponse concrète!!??
le question c'est Est ce que FireBird 1.5 différentie de la Casse ou non ?
càd : Est-ce que FB 1.5 ignore la casse ou non?
car lorsque j'insère dans un champ de type varchar (10) et de contrainte unique une chaîne qui est la même par exp :'Admin' et 'AdMin' il accepte le deux valeurs avec succès !!! c'est étonnant ??!!
Comment puis je corriger cet "erreur" pour que FB 1.5 ignore la casse ?
et Merci de me repondre .
Oui 32Ko c'est la taille max du segment et c'est ennorme ! Classiquement on utilise des tailles beaucoup plus petites. Et ce n'est pas une limitation de IBExpert, ne mélangez pas tout !Citation:
Envoyé par moucrack
Si vous n'avez pas eut de reponse c'est peut etre que vous faites fausse route. Et qu'en plus vous ne respectiez pas les règles de bon fonctionnement du forum. Vous aviez postez plusieurs fois votre problème, et au lieu de passer du temps (qui m'est compté en ce moment) à vous répondre, je l'ai passè à nettoyer le forum.Citation:
Envoyé par moucrack
Ce n'est pas parce que VOTRE BESOIN diffère du comportement de fb qu'il faut crier au BUG.
C'est tout a fait normal et standard que la différence soit faite entre les majuscules et minuscules.
Imaginez que vous enregistriez des mots de passes dans un varchar, trouveriez vous normal qu'il ne vous fasse pas de différence entre 'As4Ez2e' et 'AS4EZ2R' ?? 'masterkey' c'est différent de 'MASTERKEY' il me semble...
Le probleme d'unicité n'est pas si facile que vous l'imaginez :
Mais vous avez eut des débuts de solutions avec la préconisation de l'utilisation de 'UPPER'.
Vous avez le choix entre insérer toujours en majuscule dans ce cas avec une contrainte d'unicité (si vous souhaitez garder la version minuscule vous l'enregistrez dans une autre colonne et à ce moment là vous pouvez même utilisez un trigger before update,insert qui se chargera d'alimenter la colonne avec contrainte d'unicité avec un simple ColonneMAJUnique= UPPER(ColonneMinuscule))
Oubien vous faite un test dans un trigger before update/insert en recherchant s'il n'existe pas déjà un enregistrement et dans ce cas lever une exception. (La contrainte d'unicité étant donc ici inutile, un simple index suffit).
La première solution est plus couteuse en place disque mais est plus performante, la seconde est moins couteuse en disque mais plus lourde en traitement lors des recherches.
Voilà sur ce, je vous invite à lire et respecter les règles du forum, et de garder en tête qu'ici c'est de l'entre-aide bénévole et donc que chacun doit faire un effort pour que le forum reste une aide de qualité.
Donc effectuer des recherches, poser des questions en décrivant le plus précisément le problème et contexte, et lorsqu'on débute avec un outil se dire que les problèmes qu'on rencontre ont certainement déjà été rencontrés par des personnes plus expérimentés. Si par bonheur on vous donne la solution il est préférable de signaler qu'elle fonctionne afin que celà profite aux suivants. Si vous trouvez par vous même c'est encore mieux, et dans ce cas nous serions heureux que vous vous répondiez afin que celà profite encore une fois aux suivants. :wink:
Voilà en gros l'esprit.
Si vous avez des difficultés à mettre en oeuvre une des deux pistes que je vous ai donné, je vous invite à reprendre le fil de votre sujet initial plutot que celui-ci.
Merci
Merci Mr Barbille,
Merci de me repondre.
Concernant vos deux solutions j'ai déjà reflichi à eux. Mais, ils ne sont pas performants.Citation:
Vous avez le choix entre insérer toujours en majuscule dans ce cas avec une contrainte d'unicité (si vous souhaitez garder la version minuscule vous l'enregistrez dans une autre colonne et à ce moment là vous pouvez même utilisez un trigger before update,insert qui se chargera d'alimenter la colonne avec contrainte d'unicité avec un simple ColonneMAJUnique= UPPER(ColonneMinuscule))
Oubien vous faite un test dans un trigger before update/insert en recherchant s'il n'existe pas déjà un enregistrement et dans ce cas lever une exception. (La contrainte d'unicité étant donc ici inutile, un simple index suffit).
La première solution est plus couteuse en place disque mais est plus performante, la seconde est moins couteuse en disque mais plus lourde en traitement lors des recherches.
J'ai rencontré quelque part dans un forum qu'il existe un driver qui gère la casse des varchar. ce driver permet d'ajouter des nouveau charset des champ de type varchar (par exemple : charset = NO_CASE).
je sais pas est ce que vous avez déjà entendu parlé de ça?
Mais, ce driver n'est pas fonctionnel sous FB 1.5, il est compatible seulment avec FB 1.0!
Y a t il une autre solution ?
où est ce que vous connaissez un tel driver qui ignore la casse et qui est compatible avec FB 1.5 ?
Merci d'avence.
J'accèpte votre invitation, et désolé si j'étais un peu dûr dans les autres forums!Citation:
Voilà sur ce, je vous invite à lire et respecter les règles du forum, et de garder en tête qu'ici c'est de l'entre-aide bénévole et donc que chacun doit faire un effort pour que le forum reste une aide de qualité.
Pourquoi ??Citation:
Envoyé par moucrack
Un drivers ou un charset qui serait "case insensitive" fait à un moment donné un UPPER de la chaine afin de pouvoir la comparer. Et donc exactement ce que vous feriez soit dans votre programme soit dans votre trigger. L'écart de performance s'il est mesurable doit être petit a mon avis.
http://www.brookstonesystems.com/Citation:
Envoyé par moucrack
ce n'est pas un qu'un driver, il modifie les tables systemes également sans compter que c'est disponnible que sous windows et plus maintenu depuis au moins 2/3 ans...
Mais j'ai lu quelque part qu'il fonctionnait avec fb1.5, simplement comme fb1.5 n'utilise plus gdsintl.dll mais fbintl.dll, Ibcollate ne trouve pas la DLL.
Il suffirait de faire un lien de fbintl.dll vers gdsintl.dll ou de copier simplement fbintl.dll en gdsintl.dll pour que celà fonctionne avec fb1.5.
Je n'ai pas testé, car je ne suis pas interressé par des produits qui ne sont visiblements plus maintenu. Mais si vous essayez n'oubliez pas de nous faire part de votre expérience.
Pas à ma connaissance, peut être fb2 apportera t il une solution avec l'ajout de collations "case insensitive".Citation:
Envoyé par moucrack
Merci,
:D Très bien, Vous avez trouvé le site que j'ai l'oublié ! :wow:
l'autre fois où j'ai visité ce site, j'ai téléchargé le driver (ibcollate) et malgès qu'il ne supporte pas fb 1.5 j'ai l'installé sur ce dernier (en mettant les dll sous le dossier intl du fb 1.5. (comme mentionné dans le fichier de config)Citation:
http://www.brookstonesystems.com/
ce n'est pas un qu'un driver, il modifie les tables systemes également sans compter que c'est disponnible que sous windows et plus maintenu depuis au moins 2/3 ans...
les resulats :
j'ai remarqué qu'il y a des nouveaux charset qui sont ajoutés comme FR_FR_NOCASE et d'autres. Et quand je change le charset de mon champ de type varchar, le FB 1.5 se plante!!
Donc, pour le moment j'ai pas vraiment une très bonne solution comme celle du SQL Sever (il gère automatiquement la casse). En effet, qds vous avez un champ unique dans une table, le SGBD (exp SQL Server) ignore la casse. Et c'est ça qui a été demandé par tous les utilisateurs du SGBD.
Et dans ce cas, quand vous voulez que le sgbd n'ignore pas la casse comme le cas du (mot de passe), tout simplement vous ne mettez pas la contrainte d'unicité sur le champ qui va contenir la valeur du mot de passe. Et on peut avoir même mot de passe pour plusieurs login, mais pas le contraire.
Résumant, y a t il vraiment une solution concrète (autres que ceux déjà mentionnés tout au long du ce forum) sous fb 1.5 pour qu'il ignore la casse dans le cas où j'ai un champ de type varchar et de contrainte unique???? :?: :idea: .
càd je veux avoir une solution comme seule des autres SGBD comme SQL Server, Oracle, ..
Et s'il n 'ya pas d'autres solutions concrètes, est ce que on peut mentionner ça comme un Bug sous FB 1.5 ou non?
He Barbibulle où êtes-vous ? :koi:
quel est votre prochaine reponse ? :idea:
y a quelqu'un qui sait comment ignorer la casse sous firebird 1.5 ?? :?:
Car vraiment j'ai besoins d'une solution très urgente (SVP). et Merci pour tous.