J'ai une stats a faire : Calculer un taux de rotation de mes stocks !
Mon calcul est simple !
Dans un premier temps je calcul les stocks et en fonction des plages ded
localisations je les affectes a un pole d'activité !
Ensuite je calcul le nombre de livraisons sur une période et pour finir je
croise mes données pour avoir au final :
article : ABC, Qte stock = 500, 5 ventes sur 12 mois de 20 pièces, alors je
peux calculer mon stock en b de mois !
Ma question en programmation est comment je peux faire pour calculer une
requete puis une autre requete puis une troisième pour regrouper les deux
première ???
Ca peut etre un peu confu ?!
Pour tout vous dire, j'arrive a le faire dans ACCESS en stockant le résultat
dans des tables ttemporaires et en basant mes requetes sur ces tables !
Ne me parlez pas de requetes imbriquées ! Vu le niveau de complexité de mes
requetes je vais etre perdu ! je ne suis meme pas sur que se soit faisable !
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Fred
Dans son message % aitoz nous dit :
Bonjour,
Bonjour,
[]
Ne me parlez pas de requetes imbriquées ! Vu le niveau de complexité de mes requetes je vais etre perdu ! je ne suis meme pas sur que se soit faisable !
Mais si, mais si :-) Et comme avec Access (si tu as l'Enterprise Manager, mais je suppose que oui) Tu crées une vue, avec l'éditeur graphique et en ajoutant autant de tables que tu veux. Puis tu recopies ton code SQL dans une procédure stockée. Rapide, et en plus efficace puisque tout le travail sera compilé et exécuté par SQL Server.
-- Fred
Dans son message %23xlLO80TFHA.2768@tk2msftngp13.phx.gbl
aitoz nous dit :
Bonjour,
Bonjour,
[]
Ne me parlez pas de requetes imbriquées ! Vu le niveau de complexité
de mes requetes je vais etre perdu ! je ne suis meme pas sur que se
soit faisable !
Mais si, mais si :-)
Et comme avec Access (si tu as l'Enterprise Manager, mais je suppose que
oui)
Tu crées une vue, avec l'éditeur graphique et en ajoutant autant de tables
que tu veux.
Puis tu recopies ton code SQL dans une procédure stockée.
Rapide, et en plus efficace puisque tout le travail sera compilé et exécuté
par SQL Server.
Ne me parlez pas de requetes imbriquées ! Vu le niveau de complexité de mes requetes je vais etre perdu ! je ne suis meme pas sur que se soit faisable !
Mais si, mais si :-) Et comme avec Access (si tu as l'Enterprise Manager, mais je suppose que oui) Tu crées une vue, avec l'éditeur graphique et en ajoutant autant de tables que tu veux. Puis tu recopies ton code SQL dans une procédure stockée. Rapide, et en plus efficace puisque tout le travail sera compilé et exécuté par SQL Server.
-- Fred
aitoz
Oui,
je pourrais faire ca si ma base de données serait SQL Server ! Mais ce n'est pas le cas ! c'est une foxpro 2.0, une vielle base.
Alors les procédures stockées ca ne marche pas ! J'en fais des requetes imbriquées, mais la c'est super chaud ! Je dois regrouper la somme des qté d'une table des stocks Ensuite regrouper la somme des qté et le nb de livraisons et ensuite regrouper les deux tables !
si vous avez une idée ?
Oui,
je pourrais faire ca si ma base de données serait SQL Server !
Mais ce n'est pas le cas ! c'est une foxpro 2.0, une vielle base.
Alors les procédures stockées ca ne marche pas !
J'en fais des requetes imbriquées, mais la c'est super chaud !
Je dois regrouper la somme des qté d'une table des stocks
Ensuite regrouper la somme des qté et le nb de livraisons
et ensuite regrouper les deux tables !
je pourrais faire ca si ma base de données serait SQL Server ! Mais ce n'est pas le cas ! c'est une foxpro 2.0, une vielle base.
Alors les procédures stockées ca ne marche pas ! J'en fais des requetes imbriquées, mais la c'est super chaud ! Je dois regrouper la somme des qté d'une table des stocks Ensuite regrouper la somme des qté et le nb de livraisons et ensuite regrouper les deux tables !
si vous avez une idée ?
Fred
Dans son message aitoz nous dit :
Oui,
je pourrais faire ca si ma base de données serait SQL Server ! Mais ce n'est pas le cas ! c'est une foxpro 2.0, une vielle base.
Alors les procédures stockées ca ne marche pas ! J'en fais des requetes imbriquées, mais la c'est super chaud ! Je dois regrouper la somme des qté d'une table des stocks Ensuite regrouper la somme des qté et le nb de livraisons et ensuite regrouper les deux tables !
si vous avez une idée ?
:-D Oui effectivement, si quand je vois SQL j'ajoute Server ça ne va plus. Désolé. J'ignore ce que peut supporter foxpro :( Je le ferais en requêtes imbriquées quitte à passer un mauvais moment.
Sinon il y a peut-être des solutions avec des Datasets mais ce n'est pas mon truc. Demande peut-être sur microsoft.public.fr.dotnet.adonet ? Ou alors sur microsoft.public.fr.sqlserver : si tu exposes bien ton problème, il y des intervenants qui parlent le SQL couramment là bas. Ils mettront moins de temps à écrire la requête que moi à te répondre :-)
-- Fred
Dans son message uGeOIR1TFHA.2756@tk2msftngp13.phx.gbl
aitoz nous dit :
Oui,
je pourrais faire ca si ma base de données serait SQL Server !
Mais ce n'est pas le cas ! c'est une foxpro 2.0, une vielle base.
Alors les procédures stockées ca ne marche pas !
J'en fais des requetes imbriquées, mais la c'est super chaud !
Je dois regrouper la somme des qté d'une table des stocks
Ensuite regrouper la somme des qté et le nb de livraisons
et ensuite regrouper les deux tables !
si vous avez une idée ?
:-D
Oui effectivement, si quand je vois SQL j'ajoute Server ça ne va plus.
Désolé.
J'ignore ce que peut supporter foxpro :(
Je le ferais en requêtes imbriquées quitte à passer un mauvais moment.
Sinon il y a peut-être des solutions avec des Datasets mais ce n'est pas mon
truc.
Demande peut-être sur microsoft.public.fr.dotnet.adonet ?
Ou alors sur microsoft.public.fr.sqlserver : si tu exposes bien ton
problème, il y des intervenants qui parlent le SQL couramment là bas. Ils
mettront moins de temps à écrire la requête que moi à te répondre :-)
je pourrais faire ca si ma base de données serait SQL Server ! Mais ce n'est pas le cas ! c'est une foxpro 2.0, une vielle base.
Alors les procédures stockées ca ne marche pas ! J'en fais des requetes imbriquées, mais la c'est super chaud ! Je dois regrouper la somme des qté d'une table des stocks Ensuite regrouper la somme des qté et le nb de livraisons et ensuite regrouper les deux tables !
si vous avez une idée ?
:-D Oui effectivement, si quand je vois SQL j'ajoute Server ça ne va plus. Désolé. J'ignore ce que peut supporter foxpro :( Je le ferais en requêtes imbriquées quitte à passer un mauvais moment.
Sinon il y a peut-être des solutions avec des Datasets mais ce n'est pas mon truc. Demande peut-être sur microsoft.public.fr.dotnet.adonet ? Ou alors sur microsoft.public.fr.sqlserver : si tu exposes bien ton problème, il y des intervenants qui parlent le SQL couramment là bas. Ils mettront moins de temps à écrire la requête que moi à te répondre :-)
-- Fred
aitoz
Merci, je vais poser la question sur le forum sql server !
Merci, je vais poser la question sur le forum sql server !
Merci, je vais poser la question sur le forum sql server !
Patrick Philippot
aitoz wrote:
Ma question en programmation est comment je peux faire pour calculer une requete puis une autre requete puis une troisième pour regrouper les deux première ???
Bonjour,
La méthode de travail en ADO .Net sera légèrement différente mais les Dataset sont là pour répondre (en partie pour le moment) à ce genre de besoins.
1. Vous créez un Dataset.
2. Avec un DataAdapter, vous envoyez à la base de données la première requête et vous stockez le résultat dans la table A dans le DataSet.
3. Idem avec la deuxième requête et vous stockez le résultat dans la table B du même DataSet.
4. Vous avez donc maintenant à votre disposition un DataSet qui contient 2 tables correspondant aux résultats des 2 requêtes.
5. C'est là que la méthode diverge avec ce que vous faîtes actuellement. Puisque vous ne voulez/pouvez pas faire de merge directement au niveau de votre BD, il va vous falloir combiner les données des deux tables pour produire le résultat que vous souhaitez. Pour ce faire, vous allez utiliser la méthode DataTable.Select sur chacune des 2 première tables pour alimenter une troisième table.
En effet, si un DataSet n'est pas un SGBD complet (vous ne pouvez pas - pour le moment - envoyer une requête SQL sur un DataSet), DataTable.Select permet de faire des recherches, de filtrer, etc. Une utilisation judicieuse de cette méthode vous permettra probablement de calculer les résultats voulus à partir des données des deux tables initiales.
Si cette approche ne convient pas, il vous faudra utiliser une manière de faire plus orthodoxe et utiliser des requêtes SQL plus élaborées, ce qui est a priori la méthode la plus efficace.
-- Patrick Philippot - Microsoft MVP MainSoft Consulting Services www.mainsoft.fr
aitoz wrote:
Ma question en programmation est comment je peux faire pour calculer
une requete puis une autre requete puis une troisième pour regrouper
les deux première ???
Bonjour,
La méthode de travail en ADO .Net sera légèrement différente mais les
Dataset sont là pour répondre (en partie pour le moment) à ce genre de
besoins.
1. Vous créez un Dataset.
2. Avec un DataAdapter, vous envoyez à la base de données la première
requête et vous stockez le résultat dans la table A dans le DataSet.
3. Idem avec la deuxième requête et vous stockez le résultat dans la
table B du même DataSet.
4. Vous avez donc maintenant à votre disposition un DataSet qui contient
2 tables correspondant aux résultats des 2 requêtes.
5. C'est là que la méthode diverge avec ce que vous faîtes actuellement.
Puisque vous ne voulez/pouvez pas faire de merge directement au niveau
de votre BD, il va vous falloir combiner les données des deux tables
pour produire le résultat que vous souhaitez. Pour ce faire, vous allez
utiliser la méthode DataTable.Select sur chacune des 2 première tables
pour alimenter une troisième table.
En effet, si un DataSet n'est pas un SGBD complet (vous ne pouvez pas -
pour le moment - envoyer une requête SQL sur un DataSet),
DataTable.Select permet de faire des recherches, de filtrer, etc. Une
utilisation judicieuse de cette méthode vous permettra probablement de
calculer les résultats voulus à partir des données des deux tables
initiales.
Si cette approche ne convient pas, il vous faudra utiliser une manière
de faire plus orthodoxe et utiliser des requêtes SQL plus élaborées, ce
qui est a priori la méthode la plus efficace.
--
Patrick Philippot - Microsoft MVP
MainSoft Consulting Services
www.mainsoft.fr
Ma question en programmation est comment je peux faire pour calculer une requete puis une autre requete puis une troisième pour regrouper les deux première ???
Bonjour,
La méthode de travail en ADO .Net sera légèrement différente mais les Dataset sont là pour répondre (en partie pour le moment) à ce genre de besoins.
1. Vous créez un Dataset.
2. Avec un DataAdapter, vous envoyez à la base de données la première requête et vous stockez le résultat dans la table A dans le DataSet.
3. Idem avec la deuxième requête et vous stockez le résultat dans la table B du même DataSet.
4. Vous avez donc maintenant à votre disposition un DataSet qui contient 2 tables correspondant aux résultats des 2 requêtes.
5. C'est là que la méthode diverge avec ce que vous faîtes actuellement. Puisque vous ne voulez/pouvez pas faire de merge directement au niveau de votre BD, il va vous falloir combiner les données des deux tables pour produire le résultat que vous souhaitez. Pour ce faire, vous allez utiliser la méthode DataTable.Select sur chacune des 2 première tables pour alimenter une troisième table.
En effet, si un DataSet n'est pas un SGBD complet (vous ne pouvez pas - pour le moment - envoyer une requête SQL sur un DataSet), DataTable.Select permet de faire des recherches, de filtrer, etc. Une utilisation judicieuse de cette méthode vous permettra probablement de calculer les résultats voulus à partir des données des deux tables initiales.
Si cette approche ne convient pas, il vous faudra utiliser une manière de faire plus orthodoxe et utiliser des requêtes SQL plus élaborées, ce qui est a priori la méthode la plus efficace.
-- Patrick Philippot - Microsoft MVP MainSoft Consulting Services www.mainsoft.fr
aitoz
Je fais une recherche dans ce sens ! je m'oriente plus vers une requete SQL plus élaborée. Pour l'instant, je pense etre sur le point de reussir !
Effectivement, la lacune d'un DataSet est que l'on ne peut effectuer de requete SQL dessus ! La gestion des DataSet s'en trouve alourdi au dév et surtout a la maintenance du projet ! Revenir 8 mois plus tard sur ce genre de problématique est très couteux en temps, et en patience !
Merci beaucoup pour votre réponse.
Je fais une recherche dans ce sens ! je m'oriente plus vers une requete SQL
plus élaborée.
Pour l'instant, je pense etre sur le point de reussir !
Effectivement, la lacune d'un DataSet est que l'on ne peut effectuer de
requete SQL dessus !
La gestion des DataSet s'en trouve alourdi au dév et surtout a la
maintenance du projet !
Revenir 8 mois plus tard sur ce genre de problématique est très couteux en
temps, et en patience !
Je fais une recherche dans ce sens ! je m'oriente plus vers une requete SQL plus élaborée. Pour l'instant, je pense etre sur le point de reussir !
Effectivement, la lacune d'un DataSet est que l'on ne peut effectuer de requete SQL dessus ! La gestion des DataSet s'en trouve alourdi au dév et surtout a la maintenance du projet ! Revenir 8 mois plus tard sur ce genre de problématique est très couteux en temps, et en patience !
