windev et microsoft sql

Le
free
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.

Si vous avez des info, merci d'avances
a+
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses Page 1 / 3
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Alex
Le #20348311
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
Le #20348391
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.



http://www.sqlmanagerx.com/websqlx/html/modules/icontent/index.php?pageA

A+

--
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
Le #20348751
Il faudra que je le teste celui-la un de ces quatre.
;)
Gilles
Le #20349191
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.
Gilles
Le #20349181
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.
Firetox
Le #20349291
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
@+
free
Le #20349451
Merci à tous pour vos réponses.
Je vais essayer sqlmanagerx


"Firetox" 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
Le #20349541
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
Le #20349731
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
@+
Alex
Le #20350261
> 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.
Publicité
Poster une réponse
Anonyme