Dans son message précédent, Alex a écrit :Salut
Bonjour,Le plus gros avantage que présentent quand même les procédures
stockées sous HF CS c'est de pouvoir les écrire en WinDev et non pas
en PL/SQL comme c'est le cas jusqu'à présent sur les autres DBB les
plus connues.
Ah, c'est avantageux d'utiliser un langage propriétaire non portable ?
Dans son message précédent, Alex a écrit :
Salut
Bonjour,
Le plus gros avantage que présentent quand même les procédures
stockées sous HF CS c'est de pouvoir les écrire en WinDev et non pas
en PL/SQL comme c'est le cas jusqu'à présent sur les autres DBB les
plus connues.
Ah, c'est avantageux d'utiliser un langage propriétaire non portable ?
Dans son message précédent, Alex a écrit :Salut
Bonjour,Le plus gros avantage que présentent quand même les procédures
stockées sous HF CS c'est de pouvoir les écrire en WinDev et non pas
en PL/SQL comme c'est le cas jusqu'à présent sur les autres DBB les
plus connues.
Ah, c'est avantageux d'utiliser un langage propriétaire non portable ?
Salut
Pour les procédures stockées appellées depuis une requête, je ne
pense pas que cela soit possible dans la mesure où ces dernières
devront être appelées à partir d'une fonction propre à WinDev.
Au cours de la session de question réponse, j'ai demandé si comme en
PL/SQL ces dernières pourraient retourner des valeurs et il m'a été
répondu que Oui. Mais de la à utiliser cette valeur retournée
directement dans un Select, je ne vois comment à moins que ce soit
directement la fonction d'exécution des procédures stockées de
WinDev qui renvoie la valeur du style ouvre() qui renvoie la valeur
renvoyée à la fermeture de la fenêtre ...
Salut
Pour les procédures stockées appellées depuis une requête, je ne
pense pas que cela soit possible dans la mesure où ces dernières
devront être appelées à partir d'une fonction propre à WinDev.
Au cours de la session de question réponse, j'ai demandé si comme en
PL/SQL ces dernières pourraient retourner des valeurs et il m'a été
répondu que Oui. Mais de la à utiliser cette valeur retournée
directement dans un Select, je ne vois comment à moins que ce soit
directement la fonction d'exécution des procédures stockées de
WinDev qui renvoie la valeur du style ouvre() qui renvoie la valeur
renvoyée à la fermeture de la fenêtre ...
Salut
Pour les procédures stockées appellées depuis une requête, je ne
pense pas que cela soit possible dans la mesure où ces dernières
devront être appelées à partir d'une fonction propre à WinDev.
Au cours de la session de question réponse, j'ai demandé si comme en
PL/SQL ces dernières pourraient retourner des valeurs et il m'a été
répondu que Oui. Mais de la à utiliser cette valeur retournée
directement dans un Select, je ne vois comment à moins que ce soit
directement la fonction d'exécution des procédures stockées de
WinDev qui renvoie la valeur du style ouvre() qui renvoie la valeur
renvoyée à la fermeture de la fenêtre ...
Romain PETIT a émis l'idée suivante :
> Dans son message précédent, Alex a écrit :
>> Salut
>
> Bonjour,
>
>> Le plus gros avantage que présentent quand même les procédures
>> stockées sous HF CS c'est de pouvoir les écrire en WinDev et non p as
>> en PL/SQL comme c'est le cas jusqu'à présent sur les autres DBB les
>> plus connues.
>
> Ah, c'est avantageux d'utiliser un langage propriétaire non portable ?
Puisque le pilote ODBC va être en écriture (!!!!), ces PS seront-elle s utilisables au travers de l'ODBC?
--
Pascal
Ne garder que le prénom pour me joindre
Romain PETIT a émis l'idée suivante :
> Dans son message précédent, Alex a écrit :
>> Salut
>
> Bonjour,
>
>> Le plus gros avantage que présentent quand même les procédures
>> stockées sous HF CS c'est de pouvoir les écrire en WinDev et non p as
>> en PL/SQL comme c'est le cas jusqu'à présent sur les autres DBB les
>> plus connues.
>
> Ah, c'est avantageux d'utiliser un langage propriétaire non portable ?
Puisque le pilote ODBC va être en écriture (!!!!), ces PS seront-elle s utilisables au travers de l'ODBC?
--
Pascal
N0.pascal.SPAM@efpe.biz
Ne garder que le prénom pour me joindre
Romain PETIT a émis l'idée suivante :
> Dans son message précédent, Alex a écrit :
>> Salut
>
> Bonjour,
>
>> Le plus gros avantage que présentent quand même les procédures
>> stockées sous HF CS c'est de pouvoir les écrire en WinDev et non p as
>> en PL/SQL comme c'est le cas jusqu'à présent sur les autres DBB les
>> plus connues.
>
> Ah, c'est avantageux d'utiliser un langage propriétaire non portable ?
Puisque le pilote ODBC va être en écriture (!!!!), ces PS seront-elle s utilisables au travers de l'ODBC?
--
Pascal
Ne garder que le prénom pour me joindre
Alex a écrit :
> Salut
>
> Pour les procédures stockées appellées depuis une requête, je ne
> pense pas que cela soit possible dans la mesure où ces dernières
> devront être appelées à partir d'une fonction propre à WinDev.
>
> Au cours de la session de question réponse, j'ai demandé si comme en
> PL/SQL ces dernières pourraient retourner des valeurs et il m'a ét é
> répondu que Oui. Mais de la à utiliser cette valeur retournée
> directement dans un Select, je ne vois comment à moins que ce soit
> directement la fonction d'exécution des procédures stockées de
> WinDev qui renvoie la valeur du style ouvre() qui renvoie la valeur
> renvoyée à la fermeture de la fenêtre ...
Il faut bien insister : dans ta question, "retourner une valeur" sous
entend fonction à mon sens. C'est la fonction qui renvoie une valeur.
Ensuite tu as la procédure stockée en tant que telle, tu passes des
paramètres de type IN, OUT, INOUT. La je te rassure ce n'est pas
possible de mettre une procédure dans une requete sql. Pour finir tu
as les packages qui rassemblent des procédures et des fonctions.
Le but de mettre une fonction dans un select c'est :
select c.id_commande,
NombreArticles(c.id_commande),
DateEnvoi(c.id_commande)
from commandes c
ce qui permet d'éviter d'alourdir la requete.
Alex a écrit :
> Salut
>
> Pour les procédures stockées appellées depuis une requête, je ne
> pense pas que cela soit possible dans la mesure où ces dernières
> devront être appelées à partir d'une fonction propre à WinDev.
>
> Au cours de la session de question réponse, j'ai demandé si comme en
> PL/SQL ces dernières pourraient retourner des valeurs et il m'a ét é
> répondu que Oui. Mais de la à utiliser cette valeur retournée
> directement dans un Select, je ne vois comment à moins que ce soit
> directement la fonction d'exécution des procédures stockées de
> WinDev qui renvoie la valeur du style ouvre() qui renvoie la valeur
> renvoyée à la fermeture de la fenêtre ...
Il faut bien insister : dans ta question, "retourner une valeur" sous
entend fonction à mon sens. C'est la fonction qui renvoie une valeur.
Ensuite tu as la procédure stockée en tant que telle, tu passes des
paramètres de type IN, OUT, INOUT. La je te rassure ce n'est pas
possible de mettre une procédure dans une requete sql. Pour finir tu
as les packages qui rassemblent des procédures et des fonctions.
Le but de mettre une fonction dans un select c'est :
select c.id_commande,
NombreArticles(c.id_commande),
DateEnvoi(c.id_commande)
from commandes c
ce qui permet d'éviter d'alourdir la requete.
Alex a écrit :
> Salut
>
> Pour les procédures stockées appellées depuis une requête, je ne
> pense pas que cela soit possible dans la mesure où ces dernières
> devront être appelées à partir d'une fonction propre à WinDev.
>
> Au cours de la session de question réponse, j'ai demandé si comme en
> PL/SQL ces dernières pourraient retourner des valeurs et il m'a ét é
> répondu que Oui. Mais de la à utiliser cette valeur retournée
> directement dans un Select, je ne vois comment à moins que ce soit
> directement la fonction d'exécution des procédures stockées de
> WinDev qui renvoie la valeur du style ouvre() qui renvoie la valeur
> renvoyée à la fermeture de la fenêtre ...
Il faut bien insister : dans ta question, "retourner une valeur" sous
entend fonction à mon sens. C'est la fonction qui renvoie une valeur.
Ensuite tu as la procédure stockée en tant que telle, tu passes des
paramètres de type IN, OUT, INOUT. La je te rassure ce n'est pas
possible de mettre une procédure dans une requete sql. Pour finir tu
as les packages qui rassemblent des procédures et des fonctions.
Le but de mettre une fonction dans un select c'est :
select c.id_commande,
NombreArticles(c.id_commande),
DateEnvoi(c.id_commande)
from commandes c
ce qui permet d'éviter d'alourdir la requete.
Salut
En effet les procédures vont permettre de réaliser de nombreux
traitements qui ne pénaliseront pas les perfomances en terme de
transit de données.
Le plus gros avantage que présentent quand même les procédures
stockées sous HF CS c'est de pouvoir les écrire en WinDev et non pas
en PL/SQL comme c'est le cas jusqu'à présent sur les autres DBB les
plus connues.
Reste à voir réellement l'impact que cela aura sur les requêtes des
autres utilisateurs.
Salut
En effet les procédures vont permettre de réaliser de nombreux
traitements qui ne pénaliseront pas les perfomances en terme de
transit de données.
Le plus gros avantage que présentent quand même les procédures
stockées sous HF CS c'est de pouvoir les écrire en WinDev et non pas
en PL/SQL comme c'est le cas jusqu'à présent sur les autres DBB les
plus connues.
Reste à voir réellement l'impact que cela aura sur les requêtes des
autres utilisateurs.
Salut
En effet les procédures vont permettre de réaliser de nombreux
traitements qui ne pénaliseront pas les perfomances en terme de
transit de données.
Le plus gros avantage que présentent quand même les procédures
stockées sous HF CS c'est de pouvoir les écrire en WinDev et non pas
en PL/SQL comme c'est le cas jusqu'à présent sur les autres DBB les
plus connues.
Reste à voir réellement l'impact que cela aura sur les requêtes des
autres utilisateurs.
Salut
La seule chose que je voulais dire c'est qu'il ne sera pas nécessaire
de connaitre le PL/SQL pour pouvoir utiliser les procédures stockées.
N'importe quel développeur utilisant une base de données HF en C/S
pouerra écrire ses propres procédures stockées contrairement aux
bases comme SQL S. ou O..... ou la connaissance du PL/SQL est
nécessaire.
La problème de la portabilité du code de ces procédures stockées
n'est pas en question.
Pour en revenir à ta remarque, je ne pense pas que cette dernière
n'est pas des plus constructives.
Si tu trouves que les produits de PC
Soft présentent plus d'inconvénient que d'avantage pourquoi les
utilises tu et surtout pourquoi es tu présent sur ce forum si ce n'est
pour critiquer ...
Salut
La seule chose que je voulais dire c'est qu'il ne sera pas nécessaire
de connaitre le PL/SQL pour pouvoir utiliser les procédures stockées.
N'importe quel développeur utilisant une base de données HF en C/S
pouerra écrire ses propres procédures stockées contrairement aux
bases comme SQL S. ou O..... ou la connaissance du PL/SQL est
nécessaire.
La problème de la portabilité du code de ces procédures stockées
n'est pas en question.
Pour en revenir à ta remarque, je ne pense pas que cette dernière
n'est pas des plus constructives.
Si tu trouves que les produits de PC
Soft présentent plus d'inconvénient que d'avantage pourquoi les
utilises tu et surtout pourquoi es tu présent sur ce forum si ce n'est
pour critiquer ...
Salut
La seule chose que je voulais dire c'est qu'il ne sera pas nécessaire
de connaitre le PL/SQL pour pouvoir utiliser les procédures stockées.
N'importe quel développeur utilisant une base de données HF en C/S
pouerra écrire ses propres procédures stockées contrairement aux
bases comme SQL S. ou O..... ou la connaissance du PL/SQL est
nécessaire.
La problème de la portabilité du code de ces procédures stockées
n'est pas en question.
Pour en revenir à ta remarque, je ne pense pas que cette dernière
n'est pas des plus constructives.
Si tu trouves que les produits de PC
Soft présentent plus d'inconvénient que d'avantage pourquoi les
utilises tu et surtout pourquoi es tu présent sur ce forum si ce n'est
pour critiquer ...
Alex a écrit :
> Salut
>
> En effet les procédures vont permettre de réaliser de nombreux
> traitements qui ne pénaliseront pas les perfomances en terme de
> transit de données.
C'est l'un des principaux arguments. Tu as oublié l'indépendances
Métier / IHM. Car c'est ce dernier argument qui fait souvent le plus
le poids.
> Le plus gros avantage que présentent quand même les procédures
> stockées sous HF CS c'est de pouvoir les écrire en WinDev et non pas
> en PL/SQL comme c'est le cas jusqu'à présent sur les autres DBB les
> plus connues.
Je pensais que tu écrivais en WLangage. Sinon pourquoi rapprocher
cette nouveauté du PL/SQL exclusivement ? J'accède à une base
SQL-Server j'utilise le langage procédural qui m'est fourni, j'accès
à Oracle je fait de même, j'accède à FireBird c'est pareil...
Chaque base à son langage procédural spécifique
> Reste à voir réellement l'impact que cela aura sur les requêtes d es
> autres utilisateurs.
+1
Alex a écrit :
> Salut
>
> En effet les procédures vont permettre de réaliser de nombreux
> traitements qui ne pénaliseront pas les perfomances en terme de
> transit de données.
C'est l'un des principaux arguments. Tu as oublié l'indépendances
Métier / IHM. Car c'est ce dernier argument qui fait souvent le plus
le poids.
> Le plus gros avantage que présentent quand même les procédures
> stockées sous HF CS c'est de pouvoir les écrire en WinDev et non pas
> en PL/SQL comme c'est le cas jusqu'à présent sur les autres DBB les
> plus connues.
Je pensais que tu écrivais en WLangage. Sinon pourquoi rapprocher
cette nouveauté du PL/SQL exclusivement ? J'accède à une base
SQL-Server j'utilise le langage procédural qui m'est fourni, j'accès
à Oracle je fait de même, j'accède à FireBird c'est pareil...
Chaque base à son langage procédural spécifique
> Reste à voir réellement l'impact que cela aura sur les requêtes d es
> autres utilisateurs.
+1
Alex a écrit :
> Salut
>
> En effet les procédures vont permettre de réaliser de nombreux
> traitements qui ne pénaliseront pas les perfomances en terme de
> transit de données.
C'est l'un des principaux arguments. Tu as oublié l'indépendances
Métier / IHM. Car c'est ce dernier argument qui fait souvent le plus
le poids.
> Le plus gros avantage que présentent quand même les procédures
> stockées sous HF CS c'est de pouvoir les écrire en WinDev et non pas
> en PL/SQL comme c'est le cas jusqu'à présent sur les autres DBB les
> plus connues.
Je pensais que tu écrivais en WLangage. Sinon pourquoi rapprocher
cette nouveauté du PL/SQL exclusivement ? J'accède à une base
SQL-Server j'utilise le langage procédural qui m'est fourni, j'accès
à Oracle je fait de même, j'accède à FireBird c'est pareil...
Chaque base à son langage procédural spécifique
> Reste à voir réellement l'impact que cela aura sur les requêtes d es
> autres utilisateurs.
+1
wrote:
> Alex a écrit :
>
> > Salut
> >
> > En effet les procédures vont permettre de réaliser de nombr eux
> > traitements qui ne pénaliseront pas les perfomances en terme de
> > transit de données.
>
> C'est l'un des principaux arguments. Tu as oublié l'indépenda nces
> Métier / IHM. Car c'est ce dernier argument qui fait souvent le pl us
> le poids.
>
> > Le plus gros avantage que présentent quand même les procà ©dures
> > stockées sous HF CS c'est de pouvoir les écrire en WinDev e t non pas
> > en PL/SQL comme c'est le cas jusqu'à présent sur les autres DBB les
> > plus connues.
>
> Je pensais que tu écrivais en WLangage. Sinon pourquoi rapprocher
> cette nouveauté du PL/SQL exclusivement ? J'accède à une base
> SQL-Server j'utilise le langage procédural qui m'est fourni, j'acc ès
> à Oracle je fait de même, j'accède à FireBird c'est pareil...
> Chaque base à son langage procédural spécifique
>
> > Reste à voir réellement l'impact que cela aura sur les requ êtes des
> > autres utilisateurs.
>
> +1
elecoest@gmail.com wrote:
> Alex a écrit :
>
> > Salut
> >
> > En effet les procédures vont permettre de réaliser de nombr eux
> > traitements qui ne pénaliseront pas les perfomances en terme de
> > transit de données.
>
> C'est l'un des principaux arguments. Tu as oublié l'indépenda nces
> Métier / IHM. Car c'est ce dernier argument qui fait souvent le pl us
> le poids.
>
> > Le plus gros avantage que présentent quand même les procà ©dures
> > stockées sous HF CS c'est de pouvoir les écrire en WinDev e t non pas
> > en PL/SQL comme c'est le cas jusqu'à présent sur les autres DBB les
> > plus connues.
>
> Je pensais que tu écrivais en WLangage. Sinon pourquoi rapprocher
> cette nouveauté du PL/SQL exclusivement ? J'accède à une base
> SQL-Server j'utilise le langage procédural qui m'est fourni, j'acc ès
> à Oracle je fait de même, j'accède à FireBird c'est pareil...
> Chaque base à son langage procédural spécifique
>
> > Reste à voir réellement l'impact que cela aura sur les requ êtes des
> > autres utilisateurs.
>
> +1
wrote:
> Alex a écrit :
>
> > Salut
> >
> > En effet les procédures vont permettre de réaliser de nombr eux
> > traitements qui ne pénaliseront pas les perfomances en terme de
> > transit de données.
>
> C'est l'un des principaux arguments. Tu as oublié l'indépenda nces
> Métier / IHM. Car c'est ce dernier argument qui fait souvent le pl us
> le poids.
>
> > Le plus gros avantage que présentent quand même les procà ©dures
> > stockées sous HF CS c'est de pouvoir les écrire en WinDev e t non pas
> > en PL/SQL comme c'est le cas jusqu'à présent sur les autres DBB les
> > plus connues.
>
> Je pensais que tu écrivais en WLangage. Sinon pourquoi rapprocher
> cette nouveauté du PL/SQL exclusivement ? J'accède à une base
> SQL-Server j'utilise le langage procédural qui m'est fourni, j'acc ès
> à Oracle je fait de même, j'accède à FireBird c'est pareil...
> Chaque base à son langage procédural spécifique
>
> > Reste à voir réellement l'impact que cela aura sur les requ êtes des
> > autres utilisateurs.
>
> +1
Alex a couché sur son écran :
> Salut
Bonjour,
> La seule chose que je voulais dire c'est qu'il ne sera pas nécessaire
> de connaitre le PL/SQL pour pouvoir utiliser les procédures stockée s.
> N'importe quel développeur utilisant une base de données HF en C/S
> pouerra écrire ses propres procédures stockées contrairement aux
> bases comme SQL S. ou O..... ou la connaissance du PL/SQL est
> nécessaire.
Franchement, n'est-il pas préférable qu'un développeur digne de ce nom
connaisse les bases du SQL a partir du moment où il fricote avec ce qui
ressemble à une base données ? (au moins pour sa culture
personnelle...)
> La problème de la portabilité du code de ces procédures stockées
> n'est pas en question.
Pour quelle raison ?
Parce que chaque base a son langage comme le dit Emmanuel ?
Ne serait-il pas judicieux que les codes des PS soient portables ?
(je pose la question, je suis novice en la matière)
> Pour en revenir à ta remarque, je ne pense pas que cette dernière
> n'est pas des plus constructives.
Disons qu'elle est orientée.
C'est pour rétablir un peu l'équilibre quand les sous-marins sont de
sortie...
Pourtant, c'était bien une question.
> Si tu trouves que les produits de PC
> Soft présentent plus d'inconvénient que d'avantage pourquoi les
> utilises tu et surtout pourquoi es tu présent sur ce forum si ce n'est
> pour critiquer ...
Il te suffit de faire une recherche google pour le savoir.
http://groups.google.fr/groups/profile?show=more&enc_user=oY0Z1xsAAAA cR4pRQrsin_d78aXp1-VyVaczxWsWnUPeNmnbGw26jQ&hl=fr&group=fr.comp.develop pement.agl.windev
http://groups.google.fr/groups/profile?show=more&enc_user=8OOysBMAAAA gfSFdeIOUsOKzsD4hOrUtEcqsED4MPRkyRCgLStnlSw&hl=fr&group=fr.comp.develop pement.agl.windev
Allez, je t'aide un peu en triant :
http://groups.google.fr/groups/search?hl=fr&lr=&num0&q=%22roma in+petit%22+AND+%28BUG+OR+COMMERCIALE%29+group%3Afr.comp.developpement.agl. windev&qt_s=Rechercher
--
Romain PETIT
http://cerbermail.com/?O16kfXOFcq
(cliquez sur le lien ci-dessus pour me contacter en privé)
Alex a couché sur son écran :
> Salut
Bonjour,
> La seule chose que je voulais dire c'est qu'il ne sera pas nécessaire
> de connaitre le PL/SQL pour pouvoir utiliser les procédures stockée s.
> N'importe quel développeur utilisant une base de données HF en C/S
> pouerra écrire ses propres procédures stockées contrairement aux
> bases comme SQL S. ou O..... ou la connaissance du PL/SQL est
> nécessaire.
Franchement, n'est-il pas préférable qu'un développeur digne de ce nom
connaisse les bases du SQL a partir du moment où il fricote avec ce qui
ressemble à une base données ? (au moins pour sa culture
personnelle...)
> La problème de la portabilité du code de ces procédures stockées
> n'est pas en question.
Pour quelle raison ?
Parce que chaque base a son langage comme le dit Emmanuel ?
Ne serait-il pas judicieux que les codes des PS soient portables ?
(je pose la question, je suis novice en la matière)
> Pour en revenir à ta remarque, je ne pense pas que cette dernière
> n'est pas des plus constructives.
Disons qu'elle est orientée.
C'est pour rétablir un peu l'équilibre quand les sous-marins sont de
sortie...
Pourtant, c'était bien une question.
> Si tu trouves que les produits de PC
> Soft présentent plus d'inconvénient que d'avantage pourquoi les
> utilises tu et surtout pourquoi es tu présent sur ce forum si ce n'est
> pour critiquer ...
Il te suffit de faire une recherche google pour le savoir.
http://groups.google.fr/groups/profile?show=more&enc_user=oY0Z1xsAAAA cR4pRQrsin_d78aXp1-VyVaczxWsWnUPeNmnbGw26jQ&hl=fr&group=fr.comp.develop pement.agl.windev
http://groups.google.fr/groups/profile?show=more&enc_user=8OOysBMAAAA gfSFdeIOUsOKzsD4hOrUtEcqsED4MPRkyRCgLStnlSw&hl=fr&group=fr.comp.develop pement.agl.windev
Allez, je t'aide un peu en triant :
http://groups.google.fr/groups/search?hl=fr&lr=&num=100&q=%22roma in+petit%22+AND+%28BUG+OR+COMMERCIALE%29+group%3Afr.comp.developpement.agl. windev&qt_s=Rechercher
--
Romain PETIT
http://cerbermail.com/?O16kfXOFcq
(cliquez sur le lien ci-dessus pour me contacter en privé)
Alex a couché sur son écran :
> Salut
Bonjour,
> La seule chose que je voulais dire c'est qu'il ne sera pas nécessaire
> de connaitre le PL/SQL pour pouvoir utiliser les procédures stockée s.
> N'importe quel développeur utilisant une base de données HF en C/S
> pouerra écrire ses propres procédures stockées contrairement aux
> bases comme SQL S. ou O..... ou la connaissance du PL/SQL est
> nécessaire.
Franchement, n'est-il pas préférable qu'un développeur digne de ce nom
connaisse les bases du SQL a partir du moment où il fricote avec ce qui
ressemble à une base données ? (au moins pour sa culture
personnelle...)
> La problème de la portabilité du code de ces procédures stockées
> n'est pas en question.
Pour quelle raison ?
Parce que chaque base a son langage comme le dit Emmanuel ?
Ne serait-il pas judicieux que les codes des PS soient portables ?
(je pose la question, je suis novice en la matière)
> Pour en revenir à ta remarque, je ne pense pas que cette dernière
> n'est pas des plus constructives.
Disons qu'elle est orientée.
C'est pour rétablir un peu l'équilibre quand les sous-marins sont de
sortie...
Pourtant, c'était bien une question.
> Si tu trouves que les produits de PC
> Soft présentent plus d'inconvénient que d'avantage pourquoi les
> utilises tu et surtout pourquoi es tu présent sur ce forum si ce n'est
> pour critiquer ...
Il te suffit de faire une recherche google pour le savoir.
http://groups.google.fr/groups/profile?show=more&enc_user=oY0Z1xsAAAA cR4pRQrsin_d78aXp1-VyVaczxWsWnUPeNmnbGw26jQ&hl=fr&group=fr.comp.develop pement.agl.windev
http://groups.google.fr/groups/profile?show=more&enc_user=8OOysBMAAAA gfSFdeIOUsOKzsD4hOrUtEcqsED4MPRkyRCgLStnlSw&hl=fr&group=fr.comp.develop pement.agl.windev
Allez, je t'aide un peu en triant :
http://groups.google.fr/groups/search?hl=fr&lr=&num0&q=%22roma in+petit%22+AND+%28BUG+OR+COMMERCIALE%29+group%3Afr.comp.developpement.agl. windev&qt_s=Rechercher
--
Romain PETIT
http://cerbermail.com/?O16kfXOFcq
(cliquez sur le lien ci-dessus pour me contacter en privé)
wrote:Alex a écrit :Salut
En effet les procédures vont permettre de réaliser de nombreux
traitements qui ne pénaliseront pas les perfomances en terme de
transit de données.
C'est l'un des principaux arguments. Tu as oublié l'indépendances
Métier / IHM. Car c'est ce dernier argument qui fait souvent le plus
le poids.Le plus gros avantage que présentent quand même les procédures
stockées sous HF CS c'est de pouvoir les écrire en WinDev et non pas
en PL/SQL comme c'est le cas jusqu'à présent sur les autres DBB les
plus connues.
Je pensais que tu écrivais en WLangage. Sinon pourquoi rapprocher
cette nouveauté du PL/SQL exclusivement ? J'accède à une base
SQL-Server j'utilise le langage procédural qui m'est fourni, j'accès
à Oracle je fait de même, j'accède à FireBird c'est pareil...
Chaque base à son langage procédural spécifiqueReste à voir réellement l'impact que cela aura sur les requêtes des
autres utilisateurs.
+1
elecoest@gmail.com wrote:
Alex a écrit :
Salut
En effet les procédures vont permettre de réaliser de nombreux
traitements qui ne pénaliseront pas les perfomances en terme de
transit de données.
C'est l'un des principaux arguments. Tu as oublié l'indépendances
Métier / IHM. Car c'est ce dernier argument qui fait souvent le plus
le poids.
Le plus gros avantage que présentent quand même les procédures
stockées sous HF CS c'est de pouvoir les écrire en WinDev et non pas
en PL/SQL comme c'est le cas jusqu'à présent sur les autres DBB les
plus connues.
Je pensais que tu écrivais en WLangage. Sinon pourquoi rapprocher
cette nouveauté du PL/SQL exclusivement ? J'accède à une base
SQL-Server j'utilise le langage procédural qui m'est fourni, j'accès
à Oracle je fait de même, j'accède à FireBird c'est pareil...
Chaque base à son langage procédural spécifique
Reste à voir réellement l'impact que cela aura sur les requêtes des
autres utilisateurs.
+1
wrote:Alex a écrit :Salut
En effet les procédures vont permettre de réaliser de nombreux
traitements qui ne pénaliseront pas les perfomances en terme de
transit de données.
C'est l'un des principaux arguments. Tu as oublié l'indépendances
Métier / IHM. Car c'est ce dernier argument qui fait souvent le plus
le poids.Le plus gros avantage que présentent quand même les procédures
stockées sous HF CS c'est de pouvoir les écrire en WinDev et non pas
en PL/SQL comme c'est le cas jusqu'à présent sur les autres DBB les
plus connues.
Je pensais que tu écrivais en WLangage. Sinon pourquoi rapprocher
cette nouveauté du PL/SQL exclusivement ? J'accède à une base
SQL-Server j'utilise le langage procédural qui m'est fourni, j'accès
à Oracle je fait de même, j'accède à FireBird c'est pareil...
Chaque base à son langage procédural spécifiqueReste à voir réellement l'impact que cela aura sur les requêtes des
autres utilisateurs.
+1
