C'est quoi le mieux pour utiliser ms sql et windev ?
acces natif ? ole ?
il me semblait aussi que quelqu'un avait développé une classe mais j'ai
trouvé que celle pour mysql.
Ici on a SQL Serveur, -utilisé via ODBC -ordres SQLxxxx -pas d'analyse (les modifs de la base se font avec les outils MS)
Ça marche nickel.
Romain PETIT
free a formulé la demande :
Bonjour
C'est quoi le mieux pour utiliser ms sql et windev ? acces natif ? ole ? il me semblait aussi que quelqu'un avait développé une classe mais j'ai trouvé que celle pour mysql.
-- Romain PETIT contact : http://cerbermail.com/?O16kfXOFcq +-+ posté sur Usenet avec MesNews et non depuis un forum web +-+ news:fr.comp.developpement.agl.windev http://www.mesnews.net/ http://fr.wikipedia.org/wiki/Newsgroup
free a formulé la demande :
Bonjour
C'est quoi le mieux pour utiliser ms sql et windev ?
acces natif ? ole ?
il me semblait aussi que quelqu'un avait développé une classe mais j'ai
trouvé que celle pour mysql.
--
Romain PETIT
contact : http://cerbermail.com/?O16kfXOFcq
+-+ posté sur Usenet avec MesNews et non depuis un forum web +-+
news:fr.comp.developpement.agl.windev
http://www.mesnews.net/
http://fr.wikipedia.org/wiki/Newsgroup
C'est quoi le mieux pour utiliser ms sql et windev ? acces natif ? ole ? il me semblait aussi que quelqu'un avait développé une classe mais j'ai trouvé que celle pour mysql.
-- Romain PETIT contact : http://cerbermail.com/?O16kfXOFcq +-+ posté sur Usenet avec MesNews et non depuis un forum web +-+ news:fr.comp.developpement.agl.windev http://www.mesnews.net/ http://fr.wikipedia.org/wiki/Newsgroup
Alex
Il faudra que je le teste celui-la un de ces quatre. ;)
Il faudra que je le teste celui-la un de ces quatre.
;)
Il faudra que je le teste celui-la un de ces quatre. ;)
Gilles
free a formulé la demande :
Bonjour
C'est quoi le mieux pour utiliser ms sql et windev ? acces natif ? ole ?
Le mieux c'est l'accès natif (car tu profites de l'environnement et des fonctions natives, y compris les ordres H
Et c'est quand même bien pratique de faire un ecranversfichier et un hajoute ou hmodifie sans se palucher la requête SQL et son alimentation. (Ou le contraire, charger des données en 1 ligne de code)
il me semblait aussi que quelqu'un avait développé une classe mais j'ai trouvé que celle pour mysql.
On t'a déjà donné le lien. Ces classes ont l'avantage d'être gratuite, mais au niveau confort d'utilisation c'est le jour et la nuit.
free a formulé la demande :
Bonjour
C'est quoi le mieux pour utiliser ms sql et windev ?
acces natif ? ole ?
Le mieux c'est l'accès natif (car tu profites de l'environnement et des
fonctions natives, y compris les ordres H
Et c'est quand même bien pratique de faire un ecranversfichier et un
hajoute ou hmodifie sans se palucher la requête SQL et son
alimentation.
(Ou le contraire, charger des données en 1 ligne de code)
il me semblait aussi que quelqu'un avait développé une classe mais j'ai
trouvé que celle pour mysql.
On t'a déjà donné le lien.
Ces classes ont l'avantage d'être gratuite, mais au niveau confort
d'utilisation c'est le jour et la nuit.
C'est quoi le mieux pour utiliser ms sql et windev ? acces natif ? ole ?
Le mieux c'est l'accès natif (car tu profites de l'environnement et des fonctions natives, y compris les ordres H
Et c'est quand même bien pratique de faire un ecranversfichier et un hajoute ou hmodifie sans se palucher la requête SQL et son alimentation. (Ou le contraire, charger des données en 1 ligne de code)
il me semblait aussi que quelqu'un avait développé une classe mais j'ai trouvé que celle pour mysql.
On t'a déjà donné le lien. Ces classes ont l'avantage d'être gratuite, mais au niveau confort d'utilisation c'est le jour et la nuit.
Gilles
Alex avait écrit le 14/10/2009 :
Ici on a SQL Serveur, -utilisé via ODBC -ordres SQLxxxx -pas d'analyse (les modifs de la base se font avec les outils MS)
Ça marche nickel.
Stocker les données dans un fichier dBase aussi... "ça marche niquel".
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? C'est bien la peine d'avoir une base SQL payante pour utiliser de la daube pareille pour y accéder.
Autant utiliser MySQL et l'accès natif si l'objectif est d'être radin au détriment du code.
Alex avait écrit le 14/10/2009 :
Ici on a SQL Serveur,
-utilisé via ODBC
-ordres SQLxxxx
-pas d'analyse (les modifs de la base se font avec les outils MS)
Ça marche nickel.
Stocker les données dans un fichier dBase aussi... "ça marche niquel".
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?
C'est bien la peine d'avoir une base SQL payante pour utiliser de la
daube pareille pour y accéder.
Autant utiliser MySQL et l'accès natif si l'objectif est d'être radin
au détriment du code.
Ici on a SQL Serveur, -utilisé via ODBC -ordres SQLxxxx -pas d'analyse (les modifs de la base se font avec les outils MS)
Ça marche nickel.
Stocker les données dans un fichier dBase aussi... "ça marche niquel".
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? C'est bien la peine d'avoir une base SQL payante pour utiliser de la daube pareille pour y accéder.
Autant utiliser MySQL et l'accès natif si l'objectif est d'être radin au détriment du code.
Firetox
Bonjour,
Le mieux c'est l'accès natif (car tu profites de l'environnement et des fonctions natives, y compris les ordres H
pas evident la multiplication des curseur cote serveur est un probleme les multiples connexion pour 1 seule poste aussi les blocages seulement a l'update aussi le timeOut sur les PS intouchable est genant
Et c'est quand même bien pratique de faire un ecranversfichier et un hajoute ou hmodifie sans se palucher la requête SQL et son alimentation. (Ou le contraire, charger des données en 1 ligne de code)
couplé a SQLManagerX on a la meme chose SQLtableVersEcran, SQLupdate, SQLinsert sans se préoccuper du code SQL
Ces classes ont l'avantage d'être gratuite, mais au niveau confort d'utilisation c'est le jour et la nuit.
tout depend mais faire du traitement optimisé en SQL avec les ordre H est inadequate il faut passer par SQLExec pour utiliser pleinement les possibilités du serveur donc on revient au premier point (les PS, les curseurs renvoyés par une PS, les curseurs multiples pour une seule connexion etc ...
Bon dev @+
Bonjour,
Le mieux c'est l'accès natif (car tu profites de l'environnement et des
fonctions natives, y compris les ordres H
pas evident la multiplication des curseur cote serveur est un probleme
les multiples connexion pour 1 seule poste aussi
les blocages seulement a l'update aussi
le timeOut sur les PS intouchable est genant
Et c'est quand même bien pratique de faire un ecranversfichier et un
hajoute ou hmodifie sans se palucher la requête SQL et son alimentation.
(Ou le contraire, charger des données en 1 ligne de code)
couplé a SQLManagerX on a la meme chose
SQLtableVersEcran, SQLupdate, SQLinsert sans se préoccuper du code SQL
Ces classes ont l'avantage d'être gratuite, mais au niveau confort
d'utilisation c'est le jour et la nuit.
tout depend mais faire du traitement optimisé en SQL avec les ordre H est
inadequate il faut passer par SQLExec pour utiliser pleinement les
possibilités du serveur donc on revient au premier point (les PS, les
curseurs renvoyés par une PS, les curseurs multiples pour une seule
connexion etc ...
Le mieux c'est l'accès natif (car tu profites de l'environnement et des fonctions natives, y compris les ordres H
pas evident la multiplication des curseur cote serveur est un probleme les multiples connexion pour 1 seule poste aussi les blocages seulement a l'update aussi le timeOut sur les PS intouchable est genant
Et c'est quand même bien pratique de faire un ecranversfichier et un hajoute ou hmodifie sans se palucher la requête SQL et son alimentation. (Ou le contraire, charger des données en 1 ligne de code)
couplé a SQLManagerX on a la meme chose SQLtableVersEcran, SQLupdate, SQLinsert sans se préoccuper du code SQL
Ces classes ont l'avantage d'être gratuite, mais au niveau confort d'utilisation c'est le jour et la nuit.
tout depend mais faire du traitement optimisé en SQL avec les ordre H est inadequate il faut passer par SQLExec pour utiliser pleinement les possibilités du serveur donc on revient au premier point (les PS, les curseurs renvoyés par une PS, les curseurs multiples pour une seule connexion etc ...
Bon dev @+
free
Merci à tous pour vos réponses. Je vais essayer sqlmanagerx
"Firetox" a écrit dans le message de news:4ad5c36f$0$21097$
Bonjour,
> Le mieux c'est l'accès natif (car tu profites de l'environnement et des > fonctions natives, y compris les ordres H pas evident la multiplication des curseur cote serveur est un probleme les multiples connexion pour 1 seule poste aussi les blocages seulement a l'update aussi le timeOut sur les PS intouchable est genant
> > Et c'est quand même bien pratique de faire un ecranversfichier et un > hajoute ou hmodifie sans se palucher la requête SQL et son alimentation. > (Ou le contraire, charger des données en 1 ligne de code) couplé a SQLManagerX on a la meme chose SQLtableVersEcran, SQLupdate, SQLinsert sans se préoccuper du code SQL
> Ces classes ont l'avantage d'être gratuite, mais au niveau confort > d'utilisation c'est le jour et la nuit. tout depend mais faire du traitement optimisé en SQL avec les ordre H est inadequate il faut passer par SQLExec pour utiliser pleinement les possibilités du serveur donc on revient au premier point (les PS, les curseurs renvoyés par une PS, les curseurs multiples pour une seule connexion etc ...
Bon dev @+
Merci à tous pour vos réponses.
Je vais essayer sqlmanagerx
"Firetox" <firetox@free.fr> a écrit dans le message de
news:4ad5c36f$0$21097$426a74cc@news.free.fr...
Bonjour,
> Le mieux c'est l'accès natif (car tu profites de l'environnement et des
> fonctions natives, y compris les ordres H
pas evident la multiplication des curseur cote serveur est un probleme
les multiples connexion pour 1 seule poste aussi
les blocages seulement a l'update aussi
le timeOut sur les PS intouchable est genant
>
> Et c'est quand même bien pratique de faire un ecranversfichier et un
> hajoute ou hmodifie sans se palucher la requête SQL et son alimentation.
> (Ou le contraire, charger des données en 1 ligne de code)
couplé a SQLManagerX on a la meme chose
SQLtableVersEcran, SQLupdate, SQLinsert sans se préoccuper du code SQL
> Ces classes ont l'avantage d'être gratuite, mais au niveau confort
> d'utilisation c'est le jour et la nuit.
tout depend mais faire du traitement optimisé en SQL avec les ordre H est
inadequate il faut passer par SQLExec pour utiliser pleinement les
possibilités du serveur donc on revient au premier point (les PS, les
curseurs renvoyés par une PS, les curseurs multiples pour une seule
connexion etc ...
Merci à tous pour vos réponses. Je vais essayer sqlmanagerx
"Firetox" a écrit dans le message de news:4ad5c36f$0$21097$
Bonjour,
> Le mieux c'est l'accès natif (car tu profites de l'environnement et des > fonctions natives, y compris les ordres H pas evident la multiplication des curseur cote serveur est un probleme les multiples connexion pour 1 seule poste aussi les blocages seulement a l'update aussi le timeOut sur les PS intouchable est genant
> > Et c'est quand même bien pratique de faire un ecranversfichier et un > hajoute ou hmodifie sans se palucher la requête SQL et son alimentation. > (Ou le contraire, charger des données en 1 ligne de code) couplé a SQLManagerX on a la meme chose SQLtableVersEcran, SQLupdate, SQLinsert sans se préoccuper du code SQL
> Ces classes ont l'avantage d'être gratuite, mais au niveau confort > d'utilisation c'est le jour et la nuit. tout depend mais faire du traitement optimisé en SQL avec les ordre H est inadequate il faut passer par SQLExec pour utiliser pleinement les possibilités du serveur donc on revient au premier point (les PS, les curseurs renvoyés par une PS, les curseurs multiples pour une seule connexion etc ...
Bon dev @+
Gilles
Firetox a formulé la demande :
Bonjour,
Le mieux c'est l'accès natif (car tu profites de l'environnement et des fonctions natives, y compris les ordres H
pas evident la multiplication des curseur cote serveur est un probleme les multiples connexion pour 1 seule poste aussi les blocages seulement a l'update aussi le timeOut sur les PS intouchable est genant
Et c'est quand même bien pratique de faire un ecranversfichier et un hajoute ou hmodifie sans se palucher la requête SQL et son alimentation. (Ou le contraire, charger des données en 1 ligne de code)
couplé a SQLManagerX on a la meme chose SQLtableVersEcran, SQLupdate, SQLinsert sans se préoccuper du code SQL
Ces classes ont l'avantage d'être gratuite, mais au niveau confort d'utilisation c'est le jour et la nuit.
tout depend mais faire du traitement optimisé en SQL avec les ordre H est inadequate il faut passer par SQLExec pour utiliser pleinement les possibilités du serveur donc on revient au premier point (les PS, les curseurs renvoyés par une PS, les curseurs multiples pour une seule connexion etc ...
Oui pour du traitement de masse... mais pour du traitement de masse, on préfèrera toujours les procédures stockées. 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%)
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.
Pourquoi parle tu de multiples connexions côté client? Je n'ai pas connaissance de ce problème, ca m'interesse.
Firetox a formulé la demande :
Bonjour,
Le mieux c'est l'accès natif (car tu profites de l'environnement et des
fonctions natives, y compris les ordres H
pas evident la multiplication des curseur cote serveur est un probleme
les multiples connexion pour 1 seule poste aussi
les blocages seulement a l'update aussi
le timeOut sur les PS intouchable est genant
Et c'est quand même bien pratique de faire un ecranversfichier et un
hajoute ou hmodifie sans se palucher la requête SQL et son alimentation.
(Ou le contraire, charger des données en 1 ligne de code)
couplé a SQLManagerX on a la meme chose
SQLtableVersEcran, SQLupdate, SQLinsert sans se préoccuper du code SQL
Ces classes ont l'avantage d'être gratuite, mais au niveau confort
d'utilisation c'est le jour et la nuit.
tout depend mais faire du traitement optimisé en SQL avec les ordre H est
inadequate il faut passer par SQLExec pour utiliser pleinement les
possibilités du serveur donc on revient au premier point (les PS, les
curseurs renvoyés par une PS, les curseurs multiples pour une seule connexion
etc ...
Oui pour du traitement de masse... mais pour du traitement de masse, on
préfèrera toujours les procédures stockées.
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%)
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.
Pourquoi parle tu de multiples connexions côté client? Je n'ai pas
connaissance de ce problème, ca m'interesse.
Le mieux c'est l'accès natif (car tu profites de l'environnement et des fonctions natives, y compris les ordres H
pas evident la multiplication des curseur cote serveur est un probleme les multiples connexion pour 1 seule poste aussi les blocages seulement a l'update aussi le timeOut sur les PS intouchable est genant
Et c'est quand même bien pratique de faire un ecranversfichier et un hajoute ou hmodifie sans se palucher la requête SQL et son alimentation. (Ou le contraire, charger des données en 1 ligne de code)
couplé a SQLManagerX on a la meme chose SQLtableVersEcran, SQLupdate, SQLinsert sans se préoccuper du code SQL
Ces classes ont l'avantage d'être gratuite, mais au niveau confort d'utilisation c'est le jour et la nuit.
tout depend mais faire du traitement optimisé en SQL avec les ordre H est inadequate il faut passer par SQLExec pour utiliser pleinement les possibilités du serveur donc on revient au premier point (les PS, les curseurs renvoyés par une PS, les curseurs multiples pour une seule connexion etc ...
Oui pour du traitement de masse... mais pour du traitement de masse, on préfèrera toujours les procédures stockées. 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%)
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.
Pourquoi parle tu de multiples connexions côté client? Je n'ai pas connaissance de ce problème, ca m'interesse.
Firetox
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%)
c'est aussi le cas avec SQLManagerX (c'est pour cela qu'il a ete creer) pour avoir la completion windev lorsqu'on tape le code , la V5 se passe meme de code pour les modes fiche et table le code est simple lisible et facilement maintenable (puisqu'il ressemnle aux ordres H)
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%)
c'est aussi le cas avec SQLManagerX (c'est pour cela qu'il a ete creer) pour
avoir la completion windev lorsqu'on tape le code , la V5 se passe meme de
code pour les modes fiche et table
le code est simple lisible et facilement maintenable (puisqu'il ressemnle
aux ordres H)
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 !
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%)
c'est aussi le cas avec SQLManagerX (c'est pour cela qu'il a ete creer) pour avoir la completion windev lorsqu'on tape le code , la V5 se passe meme de code pour les modes fiche et table le code est simple lisible et facilement maintenable (puisqu'il ressemnle aux ordres H)
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 @+
Alex
> 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.
