Bonjour, sur la V185+ (build 7689), j'ai l'impression d'avoir atteint la limite de création de questionnaire :

Lorsque le nombre 99 999 est atteint, il recommence la numérotation. (du moins c'est l'impression que j'ai).

Dans la capture -1- on voit le nombre de questionnaire.
Dans la capture -2- on voit la structure de la table lime_survey

Le sid est de type integer.
D'après la doc de postgresql (j'ai une 8.1.4) - www.postgresql.org/docs/8.4/static/datatype-numeric.html
on voit que le type integer a une plage de -2147483648 to +2147483647.

Je me demande si des questionnaires actifs/inactifs/expirés, ne se font pas écraser par les nouveaux créés après 99999 ?

Ces symptomes sont présent dans la V192+ et la V2 ? (deux versions présenties pour remplacer la V185+).

Ah oui,

le numéro dans le core de LS est maxi à 99999. C'est réglé sur la V2, je ne pense pas sur la v192.

Denis

Merci Denis, ma plus grande crainte est l'écrasement de questionnaire existant.
Tu pense que je fais un rapport de bug pour une vérification dans les versions supérieur à la 1.85+ (1.92+ et 2.00) ?

Salut,
Personellement j'essaie de contrôler au maximum l'ID du questionnaire (SID) dans le but de créer des blocs d'IDs bien déterminés;
Pour l'exemple, dans le cadre d'une plateforme d'entreprise utilisée par plusieurs services, je définirai au départ:
ID 0 >999: tests, démos, développement
1000 > 1999: RH
2000 > 2999: Feedbacks clients
3000 > 3999: Enquêtes internes
etc..
Celà permet, en plus d'apporter un peu d'ordre, d'éviter les "trous" dans les SID

Pour celà, au lieu de créer un questionnaire à partir de l'option "ajouter un questionnaire", il faut juste importer un questionnaire de base (1 groupe comportant une seule question), après manipulation de l'ID via un éditeur de texte ("remplacer partout 1234 par 5678")...

Hélas, impossible d'employer une méthode similaire pour les IDs des groupes et questions
Ben/

riqcles wrote: Salut,

Plus de mise à jour de la version 1.92 officielle de LimeSurvey[*] , uniquement sur la 2.0. Le nombre de questionnaires prévus de la 2.0 est beaucoup plus important. A vérifier si le même problème peux se reproduire et comment le gérer ...

Denis
*: au cas ou, j'ai cloné LS1.92 et j'y ai apporté les correctifs sur le champs "Autres" des questions multiples et "autre obligatoire" des questions à réponse unique.
gitorious.org/aksesibsurvey/aksesibsurve...mits/LimeSurvey1.92+

Salut,
Ok pour les mise à jour de la 1.92 (je regarderais la version de Denis, dès que je pourrais la télécharger).
Je vais créé un bug "informatif" pour que Carsten et les autres regardes si lorsqu'on atteint le nombre maxi de questionnaire que peut gérer LimeSurvey, comment se comporte l'application.

@benitov :
L'idée est excellente, mais je ne peux pas l'appliquer pour les différentes directions et services utilisateurs de limesurvey.
La majorité ne sont pas informaticien et assez frileux pour mettre "les mains dans la pâte".

J'aurais donc, la même problèmatique avec la version 2 dans quelques années : des milliers de questionnaires créé, désactivé, cloné, et rarement supprimés (à moi de faire le ménage).

La version actuellement en place (v1.85+) est présente depuis 2009.

Pour la reproduction du problème en V2, je vais essayer :
- de créer un jeu de test avec Selenium (création d'un questionnaire sans groupe ni questions)
- utiliser du code PHP pour réaliser une boucle (For n to 10000) pour voir les limites.

Mantis créé : bugs.limesurvey.org/view.php?id=6823

Réponse reçu pour le Mantis :
The survey ID is randomly selected so unless you have more than 99,999 surveys in your system you will not run out of numbers

Donc, pas de soucis avant d'atteindre le chiffre pharonique de 10 000 questionnaires.

Le sujet est donc clos.

Oui,

en plus je suis bête, le sid de la table survey est la clé unique .... Donc c'est géré directement dans la base. Dès que tu ne peux plus avoir de questionnaire, bug SQL ....

Denis