Discussion :

[vouvrat]

Bonjour,


Je ne suis que débutant en ce qui concerne la gestion de base et les requête SQL.

Voici ma problématique.

J'ai une base dans lequel j'ai une table (jusque la tout va bien) dans mes champs je ne remonte aucun caractère de type %*:;,.

Hors lorsque je balance ma requête je me retrouve avec un '!' dans certains champs.

Quelqu'un pourrai m'aider? ou si quelqu'un a déjà ce type comportement pourrai t-il me donner une piste?

Merci d'avance pour vos retour.

PS:
- Serveur SQL 2005
- QueryExpress

[iberserk]

Une base contient des tables et des colonnes, pas de "champs"...

dans mes champs je ne remonte aucun caractère de type %*:;,.

Il faut croire que non :-)

[elsuket]

Bonjour,

Quel type de données stockez vous dans ces colonnes ? Si ce sont des caractères non-Latins, et que la colonne est de type char ou varchar, c'est normal.

En effet de tels types utilisent l'ASCII, qui ne peut coder que les caractères Latins, ce qui occupe 1 octet par caractère.
Pour stocker des caractères non-Latins, il faut utiliser Unicode, donc les types de données nchar et nvarchar, ce qui occupe cependant deux octets par caractère.

@++

[vouvrat]

Bonjour,

désoler pour le retard dans ma réponse.

Le problème à été corriger par notre consultant.

Je ne pourrai pas vous dire ce qui à été fait, je n'était pas présent et la personne étant présente ne peu pas expliquer...(Vachement pratique de faire assisté quelqu'un qui ne pourra pas réexpliquer après...)

[SQLpro]

ha ben ça c'est pas un consultant... ou plus exactement c'est la partie "sultan" qui doit lui manquer !!!!

A +

PS : personnellement je me fais chier à faire des rapports souvent de 10 pages pour expliquer toute ce que j'ai fait, partout ou je passe chez mes clients !
Sans tracçabilité de ce qui est fait sur un serveur, vous courrez au suicide !

[fsmrel]

Sans traçabilité de ce qui est fait sur un serveur, vous courrez au suicide !

Ça me rappelle un de mes passages chez les militaires il y a une vingtaine d’années. Ils utilisaient Uniface. A l’occasion d’un audit que je fis, ils m’expliquèrent qu’à une époque ils avaient eu un gros problème de performances : pour une requête particulièrement « sensible » (comme toujours ), le temps de réponse attendu était de l’ordre de la seconde, alors que le temps de réponse « réel » était de l’ordre de deux minutes. Que firent-ils ? Shunt des la requête fournie par Uniface au bénéfice d’une requête SQL en dur (SGBD Informix). Le temps de réponse descendit à dix secondes. Ce fut mieux, mais pas encore satisfaisant. Ils continuèrent leur explication : il y avait dans le service informatique un petit génie qui, ni une ni deux, développa une routine en C sur laquelle fut branché Uniface. Temps de réponse : Ô magie ! De l’ordre de la seconde ! Soucieux de la maintenabilité du code, c'est-à-dire de la pérennité de l’application, je demandai à voir ce fameux code C : hélas ! aucune documentation, mais du code dense, impénétrable, presque aussi hermétique que du code APL. Je demandai à avoir un entretien avec le développeur mais, objecta le Colonel H* : « Il a eu la quille il y a six mois... » Hé oui, le développeur était un appelé du contingent, mathématicien dans le civil... Le défi fut désormais de poubeller sans plus tarder le code hermétique, d'en revenir à SQL, tout en conservant le temps de réponse (sans oublier de documenter...) La routine, quoi...