Et ça ne dérange pas ton responsable d'utiliser des solutions
antédilluviennes et aux performances médiocres pour accéder aux
données?
Pas de problèmes de perf ici.
Mais on n'a pas non plus une grosse charge :
150 utilisateurs sur cette appli.
Autant utiliser MySQL et l'accès natif si l'objectif est d'être radin
au détriment du code.
La plupart des applis qu'on a sont sur SQL Serveur : administration
centralisée.
Donc c'est un choix par défaut pour tout nouveau projet.
C'est bien la peine d'avoir une base SQL payante pour utiliser de la
daube pareille pour y accéder.
Quand je suis arrivé sur le projet il y avait déjà 6 ans d'existant.
Apparemment ils avaient rencontré des soucis avec l'accès natif en
WD5.
On est en v14+ODBC et pas de pb de perf particuliers,
donc pas de raison de changer.
Et ça ne dérange pas ton responsable d'utiliser des solutions
antédilluviennes et aux performances médiocres pour accéder aux
données?
Pas de problèmes de perf ici.
Mais on n'a pas non plus une grosse charge :
150 utilisateurs sur cette appli.
Autant utiliser MySQL et l'accès natif si l'objectif est d'être radin
au détriment du code.
La plupart des applis qu'on a sont sur SQL Serveur : administration
centralisée.
Donc c'est un choix par défaut pour tout nouveau projet.
C'est bien la peine d'avoir une base SQL payante pour utiliser de la
daube pareille pour y accéder.
Quand je suis arrivé sur le projet il y avait déjà 6 ans d'existant.
Apparemment ils avaient rencontré des soucis avec l'accès natif en
WD5.
On est en v14+ODBC et pas de pb de perf particuliers,
donc pas de raison de changer.
Et ça ne dérange pas ton responsable d'utiliser des solutions
antédilluviennes et aux performances médiocres pour accéder aux
données?
Pas de problèmes de perf ici.
Mais on n'a pas non plus une grosse charge :
150 utilisateurs sur cette appli.
Autant utiliser MySQL et l'accès natif si l'objectif est d'être radin
au détriment du code.
La plupart des applis qu'on a sont sur SQL Serveur : administration
centralisée.
Donc c'est un choix par défaut pour tout nouveau projet.
C'est bien la peine d'avoir une base SQL payante pour utiliser de la
daube pareille pour y accéder.
Quand je suis arrivé sur le projet il y avait déjà 6 ans d'existant.
Apparemment ils avaient rencontré des soucis avec l'accès natif en
WD5.
On est en v14+ODBC et pas de pb de perf particuliers,
donc pas de raison de changer.
Bonjour,Oui pour du traitement de masse... mais pour du traitement de masse, on
préfèrera toujours les procédures stockées.
oui et non cela impose d'avoir deux type de maintenance 1 DBA et 1 logiciel
et le code se retrouve a 2 endroit differnts les updates de version ne sont
pas toujours simples
Pour les traitements simple, je préfère 100 fois les ordres H, je préfère
un code lisible et une analyse synchrone (qui permet de drag-drop les
champs au besoin) que de multiplier à l'infini les lignes de code. (Sinon
je ferais du C# à 100%)
par contre que l'analyse soit liée a l'appli : je ne trouve pas cela tres
judicieux etre obligé de relivrer l'executable lors de la modification des
index et autre : je prefere un systeme comme SQLManagerX qui laisse au
serveur le soin de lire sur le bon index quand il fait une requete que de
donner dans l'ordre H un index qui doit figurer dans l'analyse donc
modification de l'executable pour ajouter un index utile. ca permet de tuner
une appli sans livrer l'exe et surtout sur des vrai SGBD on tune la base avec
les index pour qu'elle soit optimale mais independement de l'application
Ma priorité est le bon mix entre performances et maintenabilité.
Et je préfère upgrader un serveur que de pourrir le code. C'est bcp plus
simple.
entierement d'accord avec toi
Pourquoi parle tu de multiples connexions côté client? Je n'ai pas
connaissance de ce problème, ca m'interesse.
test a faire pour voir si cela a ete amelioré ou non mais j'ai pas envie de
repayer un acces natif pour le voir
En fait, il suffit d'avoir des tables fichiers avec des informations
multi-fichiers pour reproduire le problème.
C'est la même chose si tu remplis une table mémoire avec des informations
provenant de différentes tables.
Server. Au niveau de l'analyse, modifie la connexion (modif source de
données, utilisateur et mot de passe).
Tu verras qu'en ouvrant les fenêtres, le nombre de SPID augmente et même si
tu fermes la fenêtre, les SPID sont toujours présents.et au bon d'un moment
on est meme arrivé a avoir nombre de connexion maxi atteinte alors qu'il y
avait 10 users en utilisation et 500 connexions sur le serveur !
Bon dev
@+
Bonjour,
Oui pour du traitement de masse... mais pour du traitement de masse, on
préfèrera toujours les procédures stockées.
oui et non cela impose d'avoir deux type de maintenance 1 DBA et 1 logiciel
et le code se retrouve a 2 endroit differnts les updates de version ne sont
pas toujours simples
Pour les traitements simple, je préfère 100 fois les ordres H, je préfère
un code lisible et une analyse synchrone (qui permet de drag-drop les
champs au besoin) que de multiplier à l'infini les lignes de code. (Sinon
je ferais du C# à 100%)
par contre que l'analyse soit liée a l'appli : je ne trouve pas cela tres
judicieux etre obligé de relivrer l'executable lors de la modification des
index et autre : je prefere un systeme comme SQLManagerX qui laisse au
serveur le soin de lire sur le bon index quand il fait une requete que de
donner dans l'ordre H un index qui doit figurer dans l'analyse donc
modification de l'executable pour ajouter un index utile. ca permet de tuner
une appli sans livrer l'exe et surtout sur des vrai SGBD on tune la base avec
les index pour qu'elle soit optimale mais independement de l'application
Ma priorité est le bon mix entre performances et maintenabilité.
Et je préfère upgrader un serveur que de pourrir le code. C'est bcp plus
simple.
entierement d'accord avec toi
Pourquoi parle tu de multiples connexions côté client? Je n'ai pas
connaissance de ce problème, ca m'interesse.
test a faire pour voir si cela a ete amelioré ou non mais j'ai pas envie de
repayer un acces natif pour le voir
En fait, il suffit d'avoir des tables fichiers avec des informations
multi-fichiers pour reproduire le problème.
C'est la même chose si tu remplis une table mémoire avec des informations
provenant de différentes tables.
Server. Au niveau de l'analyse, modifie la connexion (modif source de
données, utilisateur et mot de passe).
Tu verras qu'en ouvrant les fenêtres, le nombre de SPID augmente et même si
tu fermes la fenêtre, les SPID sont toujours présents.et au bon d'un moment
on est meme arrivé a avoir nombre de connexion maxi atteinte alors qu'il y
avait 10 users en utilisation et 500 connexions sur le serveur !
Bon dev
@+
Bonjour,Oui pour du traitement de masse... mais pour du traitement de masse, on
préfèrera toujours les procédures stockées.
oui et non cela impose d'avoir deux type de maintenance 1 DBA et 1 logiciel
et le code se retrouve a 2 endroit differnts les updates de version ne sont
pas toujours simples
Pour les traitements simple, je préfère 100 fois les ordres H, je préfère
un code lisible et une analyse synchrone (qui permet de drag-drop les
champs au besoin) que de multiplier à l'infini les lignes de code. (Sinon
je ferais du C# à 100%)
par contre que l'analyse soit liée a l'appli : je ne trouve pas cela tres
judicieux etre obligé de relivrer l'executable lors de la modification des
index et autre : je prefere un systeme comme SQLManagerX qui laisse au
serveur le soin de lire sur le bon index quand il fait une requete que de
donner dans l'ordre H un index qui doit figurer dans l'analyse donc
modification de l'executable pour ajouter un index utile. ca permet de tuner
une appli sans livrer l'exe et surtout sur des vrai SGBD on tune la base avec
les index pour qu'elle soit optimale mais independement de l'application
Ma priorité est le bon mix entre performances et maintenabilité.
Et je préfère upgrader un serveur que de pourrir le code. C'est bcp plus
simple.
entierement d'accord avec toi
Pourquoi parle tu de multiples connexions côté client? Je n'ai pas
connaissance de ce problème, ca m'interesse.
test a faire pour voir si cela a ete amelioré ou non mais j'ai pas envie de
repayer un acces natif pour le voir
En fait, il suffit d'avoir des tables fichiers avec des informations
multi-fichiers pour reproduire le problème.
C'est la même chose si tu remplis une table mémoire avec des informations
provenant de différentes tables.
Server. Au niveau de l'analyse, modifie la connexion (modif source de
données, utilisateur et mot de passe).
Tu verras qu'en ouvrant les fenêtres, le nombre de SPID augmente et même si
tu fermes la fenêtre, les SPID sont toujours présents.et au bon d'un moment
on est meme arrivé a avoir nombre de connexion maxi atteinte alors qu'il y
avait 10 users en utilisation et 500 connexions sur le serveur !
Bon dev
@+
> Tu peux virer tous les index de l'analyse si ca te chante.
Ce n'est pas parce que Windev croit qu'il n'y a aucun index qu'il ne sont
pas parfaitement utilisés par le serveur.
En outre si on en est à changer des index, c'est que l'appli est encore en
phase de dev. Sinon ya un sérieux souci en amont.
Les ordres H sont interessants pour les cas simple.
Et là les index sont prix normalement en compte (ne me dis pas que tu
ajoutes des index sur les clés primaires à postériori. (hAjoute, hModifie,
hSupprime, sans prise de tête)
En outre avec une procédure de maj auto, changer de version d'appli n'est
vraiment pas un drame.
Avec une requête? Je ferais l'essai mais je suis perplexe.
Ca me rappelle vaguement quelque chose, ca date... et c'était un bug de
mémoire... je n'ai rien remarqué de spécial avec les version 10+...
Les pools de connexion restaient stables.
Bon dev
@+
> Tu peux virer tous les index de l'analyse si ca te chante.
Ce n'est pas parce que Windev croit qu'il n'y a aucun index qu'il ne sont
pas parfaitement utilisés par le serveur.
En outre si on en est à changer des index, c'est que l'appli est encore en
phase de dev. Sinon ya un sérieux souci en amont.
Les ordres H sont interessants pour les cas simple.
Et là les index sont prix normalement en compte (ne me dis pas que tu
ajoutes des index sur les clés primaires à postériori. (hAjoute, hModifie,
hSupprime, sans prise de tête)
En outre avec une procédure de maj auto, changer de version d'appli n'est
vraiment pas un drame.
Avec une requête? Je ferais l'essai mais je suis perplexe.
Ca me rappelle vaguement quelque chose, ca date... et c'était un bug de
mémoire... je n'ai rien remarqué de spécial avec les version 10+...
Les pools de connexion restaient stables.
Bon dev
@+
> Tu peux virer tous les index de l'analyse si ca te chante.
Ce n'est pas parce que Windev croit qu'il n'y a aucun index qu'il ne sont
pas parfaitement utilisés par le serveur.
En outre si on en est à changer des index, c'est que l'appli est encore en
phase de dev. Sinon ya un sérieux souci en amont.
Les ordres H sont interessants pour les cas simple.
Et là les index sont prix normalement en compte (ne me dis pas que tu
ajoutes des index sur les clés primaires à postériori. (hAjoute, hModifie,
hSupprime, sans prise de tête)
En outre avec une procédure de maj auto, changer de version d'appli n'est
vraiment pas un drame.
Avec une requête? Je ferais l'essai mais je suis perplexe.
Ca me rappelle vaguement quelque chose, ca date... et c'était un bug de
mémoire... je n'ai rien remarqué de spécial avec les version 10+...
Les pools de connexion restaient stables.
Bon dev
@+
Tu peux virer tous les index de l'analyse si ca te chante.
Ce n'est pas parce que Windev croit qu'il n'y a aucun index qu'il ne sont
pas parfaitement utilisés par le serveur.
oui on est d'accord alors pourquoi se trilblaer l'analyse si tu as un autre
moyen d'voir les nom de colonne (la completion windev comme en c ou autre
marche tres bien pas la epine d'aller faire F11 pour choisir)
mais c'est une façon de travailler et comme je n'ai pas d'analyse dans windev
j'en utilise une autre mais le resultat est le meme l'analyse ne te sert a
t"aider tout comme la completion
En outre si on en est à changer des index, c'est que l'appli est encore en
phase de dev. Sinon ya un sérieux souci en amont.
que l'analyse a un souci mais seul la charge l'aurait montré et que le dev
devait peut etre se faire autrement (requete a repensé)
Les ordres H sont interessants pour les cas simple.
Et là les index sont prix normalement en compte (ne me dis pas que tu
ajoutes des index sur les clés primaires à postériori. (hAjoute, hModifie,
hSupprime, sans prise de tête)
j'utilise SQLManagerX (et je l'ai crée pour ca ) utilise le mode fiche et
tables avec des requetes. par contre je sais exactement ce qui est fait dans
tableVersEcran ou dans SQLPRemier , ou SQLUpdate ce que je peux pas voir avec
Hmodifie et compagnie : ca evite de dire que le bug est dans SQLPremier alors
que non : on peut par contre tres bien suspecter un bug de hmodifie
En outre avec une procédure de maj auto, changer de version d'appli n'est
vraiment pas un drame.
je te l'accorde mais pour avoir travailler sur des projets comme ca : tu ne
peux pas imaginer le nombre de client qui apres une maj nous arrosait de
message pour des erreur SQL car il n'avaient pas lu le message et fait
tourner le fichier qui mettait a jour la base et les procedures stockées.
Avec une requête? Je ferais l'essai mais je suis perplexe.
je ne sais pas j'ai une version 7.5 de l'acces natif SQLServer donc j'ai pas
tester apres mais vu que pour mySQL il utilisent toujours pas
mySQL_real_connect je pense que rien n'a beaucoup changer dedans (meme pas
les lock a la lecture ou ecriture au choix du developpeur)
Ca me rappelle vaguement quelque chose, ca date... et c'était un bug de
mémoire... je n'ai rien remarqué de spécial avec les version 10+...
Les pools de connexion restaient stables.
en avait 2 pour le poste 1 donc la valeur etait correcte et un dont il etait
à 60 on en a conclu que le Set a ete fait sur le premier PID et les exec des
PS sur le deuxieme (depuis il utilise MSSQL4WD )
Tu peux virer tous les index de l'analyse si ca te chante.
Ce n'est pas parce que Windev croit qu'il n'y a aucun index qu'il ne sont
pas parfaitement utilisés par le serveur.
oui on est d'accord alors pourquoi se trilblaer l'analyse si tu as un autre
moyen d'voir les nom de colonne (la completion windev comme en c ou autre
marche tres bien pas la epine d'aller faire F11 pour choisir)
mais c'est une façon de travailler et comme je n'ai pas d'analyse dans windev
j'en utilise une autre mais le resultat est le meme l'analyse ne te sert a
t"aider tout comme la completion
En outre si on en est à changer des index, c'est que l'appli est encore en
phase de dev. Sinon ya un sérieux souci en amont.
que l'analyse a un souci mais seul la charge l'aurait montré et que le dev
devait peut etre se faire autrement (requete a repensé)
Les ordres H sont interessants pour les cas simple.
Et là les index sont prix normalement en compte (ne me dis pas que tu
ajoutes des index sur les clés primaires à postériori. (hAjoute, hModifie,
hSupprime, sans prise de tête)
j'utilise SQLManagerX (et je l'ai crée pour ca ) utilise le mode fiche et
tables avec des requetes. par contre je sais exactement ce qui est fait dans
tableVersEcran ou dans SQLPRemier , ou SQLUpdate ce que je peux pas voir avec
Hmodifie et compagnie : ca evite de dire que le bug est dans SQLPremier alors
que non : on peut par contre tres bien suspecter un bug de hmodifie
En outre avec une procédure de maj auto, changer de version d'appli n'est
vraiment pas un drame.
je te l'accorde mais pour avoir travailler sur des projets comme ca : tu ne
peux pas imaginer le nombre de client qui apres une maj nous arrosait de
message pour des erreur SQL car il n'avaient pas lu le message et fait
tourner le fichier qui mettait a jour la base et les procedures stockées.
Avec une requête? Je ferais l'essai mais je suis perplexe.
je ne sais pas j'ai une version 7.5 de l'acces natif SQLServer donc j'ai pas
tester apres mais vu que pour mySQL il utilisent toujours pas
mySQL_real_connect je pense que rien n'a beaucoup changer dedans (meme pas
les lock a la lecture ou ecriture au choix du developpeur)
Ca me rappelle vaguement quelque chose, ca date... et c'était un bug de
mémoire... je n'ai rien remarqué de spécial avec les version 10+...
Les pools de connexion restaient stables.
en avait 2 pour le poste 1 donc la valeur etait correcte et un dont il etait
à 60 on en a conclu que le Set a ete fait sur le premier PID et les exec des
PS sur le deuxieme (depuis il utilise MSSQL4WD )
Tu peux virer tous les index de l'analyse si ca te chante.
Ce n'est pas parce que Windev croit qu'il n'y a aucun index qu'il ne sont
pas parfaitement utilisés par le serveur.
oui on est d'accord alors pourquoi se trilblaer l'analyse si tu as un autre
moyen d'voir les nom de colonne (la completion windev comme en c ou autre
marche tres bien pas la epine d'aller faire F11 pour choisir)
mais c'est une façon de travailler et comme je n'ai pas d'analyse dans windev
j'en utilise une autre mais le resultat est le meme l'analyse ne te sert a
t"aider tout comme la completion
En outre si on en est à changer des index, c'est que l'appli est encore en
phase de dev. Sinon ya un sérieux souci en amont.
que l'analyse a un souci mais seul la charge l'aurait montré et que le dev
devait peut etre se faire autrement (requete a repensé)
Les ordres H sont interessants pour les cas simple.
Et là les index sont prix normalement en compte (ne me dis pas que tu
ajoutes des index sur les clés primaires à postériori. (hAjoute, hModifie,
hSupprime, sans prise de tête)
j'utilise SQLManagerX (et je l'ai crée pour ca ) utilise le mode fiche et
tables avec des requetes. par contre je sais exactement ce qui est fait dans
tableVersEcran ou dans SQLPRemier , ou SQLUpdate ce que je peux pas voir avec
Hmodifie et compagnie : ca evite de dire que le bug est dans SQLPremier alors
que non : on peut par contre tres bien suspecter un bug de hmodifie
En outre avec une procédure de maj auto, changer de version d'appli n'est
vraiment pas un drame.
je te l'accorde mais pour avoir travailler sur des projets comme ca : tu ne
peux pas imaginer le nombre de client qui apres une maj nous arrosait de
message pour des erreur SQL car il n'avaient pas lu le message et fait
tourner le fichier qui mettait a jour la base et les procedures stockées.
Avec une requête? Je ferais l'essai mais je suis perplexe.
je ne sais pas j'ai une version 7.5 de l'acces natif SQLServer donc j'ai pas
tester apres mais vu que pour mySQL il utilisent toujours pas
mySQL_real_connect je pense que rien n'a beaucoup changer dedans (meme pas
les lock a la lecture ou ecriture au choix du developpeur)
Ca me rappelle vaguement quelque chose, ca date... et c'était un bug de
mémoire... je n'ai rien remarqué de spécial avec les version 10+...
Les pools de connexion restaient stables.
en avait 2 pour le poste 1 donc la valeur etait correcte et un dont il etait
à 60 on en a conclu que le Set a ete fait sur le premier PID et les exec des
PS sur le deuxieme (depuis il utilise MSSQL4WD )
Firetox a pensé très fort :Tu peux virer tous les index de l'analyse si ca te chante.
Ce n'est pas parce que Windev croit qu'il n'y a aucun index qu'il ne
sont pas parfaitement utilisés par le serveur.
oui on est d'accord alors pourquoi se trilblaer l'analyse si tu as un
autre moyen d'voir les nom de colonne (la completion windev comme en c
ou autre marche tres bien pas la epine d'aller faire F11 pour choisir)
mais c'est une façon de travailler et comme je n'ai pas d'analyse dans
windev j'en utilise une autre mais le resultat est le meme l'analyse
ne te sert a t"aider tout comme la completion
Tout simplement pour la création de l'IHM !
C'est déjà assez pénible comme ça, si on peut dropper les champs et les
tables, le gain de temps est considérable.
Idem pour les tables issues de requêtes paramétrées.
En outre si on en est à changer des index, c'est que l'appli est
encore en phase de dev. Sinon ya un sérieux souci en amont.
que l'analyse a un souci mais seul la charge l'aurait montré et que le
dev devait peut etre se faire autrement (requete a repensé)
Tristement classique, mais là c'est en amont qu'il fallait faire des
tests de charge non?
Pas si difficile de remplir une base de données de tests non?Les ordres H sont interessants pour les cas simple.
Et là les index sont prix normalement en compte (ne me dis pas que tu
ajoutes des index sur les clés primaires à postériori. (hAjoute,
hModifie, hSupprime, sans prise de tête)
j'utilise SQLManagerX (et je l'ai crée pour ca ) utilise le mode fiche
et tables avec des requetes. par contre je sais exactement ce qui est
fait dans tableVersEcran ou dans SQLPRemier , ou SQLUpdate ce que je
peux pas voir avec Hmodifie et compagnie : ca evite de dire que le bug
est dans SQLPremier alors que non : on peut par contre tres bien
suspecter un bug de hmodifieEn outre avec une procédure de maj auto, changer de version d'appli
n'est vraiment pas un drame.
je te l'accorde mais pour avoir travailler sur des projets comme ca :
tu ne peux pas imaginer le nombre de client qui apres une maj nous
arrosait de message pour des erreur SQL car il n'avaient pas lu le
message et fait tourner le fichier qui mettait a jour la base et les
procedures stockées.
Il est exclu de demander au client de déclencher une mise à jour
manuellement.
Pour moi, le premier client connecté vérifie la version de la base de
données et execute les scripts. (et locke les autres le temps que ça
soit fait)Avec une requête? Je ferais l'essai mais je suis perplexe.
je ne sais pas j'ai une version 7.5 de l'acces natif SQLServer donc
j'ai pas tester apres mais vu que pour mySQL il utilisent toujours pas
mySQL_real_connect je pense que rien n'a beaucoup changer dedans (meme
pas les lock a la lecture ou ecriture au choix du developpeur)
J'en suis resté à la V11 avec MySQL et c'est vrai qu'il est un peu
limité (pas de possibilité d'execution des fonctions et procs dans les
requêtes paramétrées), visiblement accessibles en v12 (et suivants).Ca me rappelle vaguement quelque chose, ca date... et c'était un bug
de mémoire... je n'ai rien remarqué de spécial avec les version 10+...
Les pools de connexion restaient stables.
en avait 2 pour le poste 1 donc la valeur etait correcte et un dont il
etait à 60 on en a conclu que le Set a ete fait sur le premier PID et
les exec des PS sur le deuxieme (depuis il utilise MSSQL4WD )
En effet, et ça n'a pas été remonté au support qu'ils corrigent ça?
Firetox a pensé très fort :
Tu peux virer tous les index de l'analyse si ca te chante.
Ce n'est pas parce que Windev croit qu'il n'y a aucun index qu'il ne
sont pas parfaitement utilisés par le serveur.
oui on est d'accord alors pourquoi se trilblaer l'analyse si tu as un
autre moyen d'voir les nom de colonne (la completion windev comme en c
ou autre marche tres bien pas la epine d'aller faire F11 pour choisir)
mais c'est une façon de travailler et comme je n'ai pas d'analyse dans
windev j'en utilise une autre mais le resultat est le meme l'analyse
ne te sert a t"aider tout comme la completion
Tout simplement pour la création de l'IHM !
C'est déjà assez pénible comme ça, si on peut dropper les champs et les
tables, le gain de temps est considérable.
Idem pour les tables issues de requêtes paramétrées.
En outre si on en est à changer des index, c'est que l'appli est
encore en phase de dev. Sinon ya un sérieux souci en amont.
que l'analyse a un souci mais seul la charge l'aurait montré et que le
dev devait peut etre se faire autrement (requete a repensé)
Tristement classique, mais là c'est en amont qu'il fallait faire des
tests de charge non?
Pas si difficile de remplir une base de données de tests non?
Les ordres H sont interessants pour les cas simple.
Et là les index sont prix normalement en compte (ne me dis pas que tu
ajoutes des index sur les clés primaires à postériori. (hAjoute,
hModifie, hSupprime, sans prise de tête)
j'utilise SQLManagerX (et je l'ai crée pour ca ) utilise le mode fiche
et tables avec des requetes. par contre je sais exactement ce qui est
fait dans tableVersEcran ou dans SQLPRemier , ou SQLUpdate ce que je
peux pas voir avec Hmodifie et compagnie : ca evite de dire que le bug
est dans SQLPremier alors que non : on peut par contre tres bien
suspecter un bug de hmodifie
En outre avec une procédure de maj auto, changer de version d'appli
n'est vraiment pas un drame.
je te l'accorde mais pour avoir travailler sur des projets comme ca :
tu ne peux pas imaginer le nombre de client qui apres une maj nous
arrosait de message pour des erreur SQL car il n'avaient pas lu le
message et fait tourner le fichier qui mettait a jour la base et les
procedures stockées.
Il est exclu de demander au client de déclencher une mise à jour
manuellement.
Pour moi, le premier client connecté vérifie la version de la base de
données et execute les scripts. (et locke les autres le temps que ça
soit fait)
Avec une requête? Je ferais l'essai mais je suis perplexe.
je ne sais pas j'ai une version 7.5 de l'acces natif SQLServer donc
j'ai pas tester apres mais vu que pour mySQL il utilisent toujours pas
mySQL_real_connect je pense que rien n'a beaucoup changer dedans (meme
pas les lock a la lecture ou ecriture au choix du developpeur)
J'en suis resté à la V11 avec MySQL et c'est vrai qu'il est un peu
limité (pas de possibilité d'execution des fonctions et procs dans les
requêtes paramétrées), visiblement accessibles en v12 (et suivants).
Ca me rappelle vaguement quelque chose, ca date... et c'était un bug
de mémoire... je n'ai rien remarqué de spécial avec les version 10+...
Les pools de connexion restaient stables.
en avait 2 pour le poste 1 donc la valeur etait correcte et un dont il
etait à 60 on en a conclu que le Set a ete fait sur le premier PID et
les exec des PS sur le deuxieme (depuis il utilise MSSQL4WD )
En effet, et ça n'a pas été remonté au support qu'ils corrigent ça?
Firetox a pensé très fort :Tu peux virer tous les index de l'analyse si ca te chante.
Ce n'est pas parce que Windev croit qu'il n'y a aucun index qu'il ne
sont pas parfaitement utilisés par le serveur.
oui on est d'accord alors pourquoi se trilblaer l'analyse si tu as un
autre moyen d'voir les nom de colonne (la completion windev comme en c
ou autre marche tres bien pas la epine d'aller faire F11 pour choisir)
mais c'est une façon de travailler et comme je n'ai pas d'analyse dans
windev j'en utilise une autre mais le resultat est le meme l'analyse
ne te sert a t"aider tout comme la completion
Tout simplement pour la création de l'IHM !
C'est déjà assez pénible comme ça, si on peut dropper les champs et les
tables, le gain de temps est considérable.
Idem pour les tables issues de requêtes paramétrées.
En outre si on en est à changer des index, c'est que l'appli est
encore en phase de dev. Sinon ya un sérieux souci en amont.
que l'analyse a un souci mais seul la charge l'aurait montré et que le
dev devait peut etre se faire autrement (requete a repensé)
Tristement classique, mais là c'est en amont qu'il fallait faire des
tests de charge non?
Pas si difficile de remplir une base de données de tests non?Les ordres H sont interessants pour les cas simple.
Et là les index sont prix normalement en compte (ne me dis pas que tu
ajoutes des index sur les clés primaires à postériori. (hAjoute,
hModifie, hSupprime, sans prise de tête)
j'utilise SQLManagerX (et je l'ai crée pour ca ) utilise le mode fiche
et tables avec des requetes. par contre je sais exactement ce qui est
fait dans tableVersEcran ou dans SQLPRemier , ou SQLUpdate ce que je
peux pas voir avec Hmodifie et compagnie : ca evite de dire que le bug
est dans SQLPremier alors que non : on peut par contre tres bien
suspecter un bug de hmodifieEn outre avec une procédure de maj auto, changer de version d'appli
n'est vraiment pas un drame.
je te l'accorde mais pour avoir travailler sur des projets comme ca :
tu ne peux pas imaginer le nombre de client qui apres une maj nous
arrosait de message pour des erreur SQL car il n'avaient pas lu le
message et fait tourner le fichier qui mettait a jour la base et les
procedures stockées.
Il est exclu de demander au client de déclencher une mise à jour
manuellement.
Pour moi, le premier client connecté vérifie la version de la base de
données et execute les scripts. (et locke les autres le temps que ça
soit fait)Avec une requête? Je ferais l'essai mais je suis perplexe.
je ne sais pas j'ai une version 7.5 de l'acces natif SQLServer donc
j'ai pas tester apres mais vu que pour mySQL il utilisent toujours pas
mySQL_real_connect je pense que rien n'a beaucoup changer dedans (meme
pas les lock a la lecture ou ecriture au choix du developpeur)
J'en suis resté à la V11 avec MySQL et c'est vrai qu'il est un peu
limité (pas de possibilité d'execution des fonctions et procs dans les
requêtes paramétrées), visiblement accessibles en v12 (et suivants).Ca me rappelle vaguement quelque chose, ca date... et c'était un bug
de mémoire... je n'ai rien remarqué de spécial avec les version 10+...
Les pools de connexion restaient stables.
en avait 2 pour le poste 1 donc la valeur etait correcte et un dont il
etait à 60 on en a conclu que le Set a ete fait sur le premier PID et
les exec des PS sur le deuxieme (depuis il utilise MSSQL4WD )
En effet, et ça n'a pas été remonté au support qu'ils corrigent ça?
> Tout simplement pour la création de l'IHM !
C'est déjà assez pénible comme ça, si on peut dropper les champs et les
tables, le gain de temps est considérable.
Idem pour les tables issues de requêtes paramétrées.
Tristement classique, mais là c'est en amont qu'il fallait faire des tests
de charge non?
Pas si difficile de remplir une base de données de tests non?
Il est exclu de demander au client de déclencher une mise à jour
manuellement.
Pour moi, le premier client connecté vérifie la version de la base de
données et execute les scripts. (et locke les autres le temps que ça soit
fait)
En effet, et ça n'a pas été remonté au support qu'ils corrigent ça?
> Tout simplement pour la création de l'IHM !
C'est déjà assez pénible comme ça, si on peut dropper les champs et les
tables, le gain de temps est considérable.
Idem pour les tables issues de requêtes paramétrées.
Tristement classique, mais là c'est en amont qu'il fallait faire des tests
de charge non?
Pas si difficile de remplir une base de données de tests non?
Il est exclu de demander au client de déclencher une mise à jour
manuellement.
Pour moi, le premier client connecté vérifie la version de la base de
données et execute les scripts. (et locke les autres le temps que ça soit
fait)
En effet, et ça n'a pas été remonté au support qu'ils corrigent ça?
> Tout simplement pour la création de l'IHM !
C'est déjà assez pénible comme ça, si on peut dropper les champs et les
tables, le gain de temps est considérable.
Idem pour les tables issues de requêtes paramétrées.
Tristement classique, mais là c'est en amont qu'il fallait faire des tests
de charge non?
Pas si difficile de remplir une base de données de tests non?
Il est exclu de demander au client de déclencher une mise à jour
manuellement.
Pour moi, le premier client connecté vérifie la version de la base de
données et execute les scripts. (et locke les autres le temps que ça soit
fait)
En effet, et ça n'a pas été remonté au support qu'ils corrigent ça?
un accès natif n'est-il pas dépendant de la version de Windev utilisée ?
un accès natif n'est-il pas dépendant de la version de Windev utilisée ?
un accès natif n'est-il pas dépendant de la version de Windev utilisée ?
Gilles a écrit :Firetox a pensé très fort :
Bonsoir,
un accès natif n'est-il pas dépendant de la version de Windev utilisée ?
SI c'est le cas pour moi c'est rédhibitoire, si pour avoir une maj de l'accès
natif il faut faire une maj de Windev cela demanderait d'avoir autant de
version de Windev que de projet demandant des évolutions de tels ou tels
accès natifs.
Gilles a écrit :
Firetox a pensé très fort :
Bonsoir,
un accès natif n'est-il pas dépendant de la version de Windev utilisée ?
SI c'est le cas pour moi c'est rédhibitoire, si pour avoir une maj de l'accès
natif il faut faire une maj de Windev cela demanderait d'avoir autant de
version de Windev que de projet demandant des évolutions de tels ou tels
accès natifs.
Gilles a écrit :Firetox a pensé très fort :
Bonsoir,
un accès natif n'est-il pas dépendant de la version de Windev utilisée ?
SI c'est le cas pour moi c'est rédhibitoire, si pour avoir une maj de l'accès
natif il faut faire une maj de Windev cela demanderait d'avoir autant de
version de Windev que de projet demandant des évolutions de tels ou tels
accès natifs.
Tout simplement pour la création de l'IHM !
C'est déjà assez pénible comme ça, si on peut dropper les champs et les
tables, le gain de temps est considérable.
Idem pour les tables issues de requêtes paramétrées.
Pour moi, le premier client connecté vérifie la version de la base de
données et execute les scripts. (et locke les autres le temps que ça soit
fait)
pas forcement
tu as de plus en plus de client qui ont des bases de test avant de mettre en
prod (en fait ils ne te font pas confiance ou certain sont parano) donc il
veulent pouvoir tester certaines choses mais pas mettre la base a jour. pour
faire des tests par etapes et surtout pour un client ne jamais au grand
jamais toucher a sa base sans son accord tu risque le proces (j'ai un pote
qui s'en rapelle encore et qui s'en mord les doigts ) si sa base doit être
mise a jour il doit le savoir et le faire quand il le souhaite . et surtout
pouvoir revenir en arriere et en base et en prog sinon il fait pas la mise a
jour
En effet, et ça n'a pas été remonté au support qu'ils corrigent ça?
je pense pas vu qu'il a chnagé d'acces il se fou royallement de ce qu'il va
se passer de ce cote la
faudrait faire les tests mais pour le faire faut se payer l'acces !
Tout simplement pour la création de l'IHM !
C'est déjà assez pénible comme ça, si on peut dropper les champs et les
tables, le gain de temps est considérable.
Idem pour les tables issues de requêtes paramétrées.
Pour moi, le premier client connecté vérifie la version de la base de
données et execute les scripts. (et locke les autres le temps que ça soit
fait)
pas forcement
tu as de plus en plus de client qui ont des bases de test avant de mettre en
prod (en fait ils ne te font pas confiance ou certain sont parano) donc il
veulent pouvoir tester certaines choses mais pas mettre la base a jour. pour
faire des tests par etapes et surtout pour un client ne jamais au grand
jamais toucher a sa base sans son accord tu risque le proces (j'ai un pote
qui s'en rapelle encore et qui s'en mord les doigts ) si sa base doit être
mise a jour il doit le savoir et le faire quand il le souhaite . et surtout
pouvoir revenir en arriere et en base et en prog sinon il fait pas la mise a
jour
En effet, et ça n'a pas été remonté au support qu'ils corrigent ça?
je pense pas vu qu'il a chnagé d'acces il se fou royallement de ce qu'il va
se passer de ce cote la
faudrait faire les tests mais pour le faire faut se payer l'acces !
Tout simplement pour la création de l'IHM !
C'est déjà assez pénible comme ça, si on peut dropper les champs et les
tables, le gain de temps est considérable.
Idem pour les tables issues de requêtes paramétrées.
Pour moi, le premier client connecté vérifie la version de la base de
données et execute les scripts. (et locke les autres le temps que ça soit
fait)
pas forcement
tu as de plus en plus de client qui ont des bases de test avant de mettre en
prod (en fait ils ne te font pas confiance ou certain sont parano) donc il
veulent pouvoir tester certaines choses mais pas mettre la base a jour. pour
faire des tests par etapes et surtout pour un client ne jamais au grand
jamais toucher a sa base sans son accord tu risque le proces (j'ai un pote
qui s'en rapelle encore et qui s'en mord les doigts ) si sa base doit être
mise a jour il doit le savoir et le faire quand il le souhaite . et surtout
pouvoir revenir en arriere et en base et en prog sinon il fait pas la mise a
jour
En effet, et ça n'a pas été remonté au support qu'ils corrigent ça?
je pense pas vu qu'il a chnagé d'acces il se fou royallement de ce qu'il va
se passer de ce cote la
faudrait faire les tests mais pour le faire faut se payer l'acces !
Si, mais c'est valable pour tous les soucis lié à un outil PCSoft.
Dans ce cas là, il faudrait changer d'outil.
Il faut considérer que vouloir les "corrections" ou les évolutions
passe par la caisse tous les ans. C'est comme ça que ça marche avec cet
outil.
Si, mais c'est valable pour tous les soucis lié à un outil PCSoft.
Dans ce cas là, il faudrait changer d'outil.
Il faut considérer que vouloir les "corrections" ou les évolutions
passe par la caisse tous les ans. C'est comme ça que ça marche avec cet
outil.
Si, mais c'est valable pour tous les soucis lié à un outil PCSoft.
Dans ce cas là, il faudrait changer d'outil.
Il faut considérer que vouloir les "corrections" ou les évolutions
passe par la caisse tous les ans. C'est comme ça que ça marche avec cet
outil.