Je disose de composants J2EE (servlets et EJB, tout le tralala). On me
demande d'étudier la possibilité d'interfacer tout ce joli monde avec une
base de données SQL Server.
Y-a-t-il des possibilités pour qu'une procédure stockée sur sql server
appelle une servlet par exemple ?
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
TestMan
Franchement SQL Server, c'est pas vraiment top comme SGBD. Si t'as de la thune, ya Oracle !
Sinon, t'as la maintenant célèbre Firebird http://firebird.sourceforge.net/
Elle fait tout même le café :) Et à un drivers JDBC type4 nickel !
A+
TM
Alain ROUILLON wrote:
Bonjour à tous,
Mon problème est le suivant :
Je disose de composants J2EE (servlets et EJB, tout le tralala). On me demande d'étudier la possibilité d'interfacer tout ce joli monde avec une base de données SQL Server.
Y-a-t-il des possibilités pour qu'une procédure stockée sur sql server appelle une servlet par exemple ?
Merci d'avance pour les réponses,
Alain
Franchement SQL Server, c'est pas vraiment top comme SGBD.
Si t'as de la thune, ya Oracle !
Sinon, t'as la maintenant célèbre Firebird http://firebird.sourceforge.net/
Elle fait tout même le café :)
Et à un drivers JDBC type4 nickel !
A+
TM
Alain ROUILLON wrote:
Bonjour à tous,
Mon problème est le suivant :
Je disose de composants J2EE (servlets et EJB, tout le tralala). On me
demande d'étudier la possibilité d'interfacer tout ce joli monde avec une
base de données SQL Server.
Y-a-t-il des possibilités pour qu'une procédure stockée sur sql server
appelle une servlet par exemple ?
Franchement SQL Server, c'est pas vraiment top comme SGBD. Si t'as de la thune, ya Oracle !
Sinon, t'as la maintenant célèbre Firebird http://firebird.sourceforge.net/
Elle fait tout même le café :) Et à un drivers JDBC type4 nickel !
A+
TM
Alain ROUILLON wrote:
Bonjour à tous,
Mon problème est le suivant :
Je disose de composants J2EE (servlets et EJB, tout le tralala). On me demande d'étudier la possibilité d'interfacer tout ce joli monde avec une base de données SQL Server.
Y-a-t-il des possibilités pour qu'une procédure stockée sur sql server appelle une servlet par exemple ?
Merci d'avance pour les réponses,
Alain
Eric Naulin
Peut etre dans ce guide de transact-SQL (SQL-Server): http://sqlpro.developpez.com/TransactSQL/SQL_MSTransactSQL.html
Peut etre dans ce guide de transact-SQL (SQL-Server):
http://sqlpro.developpez.com/TransactSQL/SQL_MSTransactSQL.html
Peut etre dans ce guide de transact-SQL (SQL-Server): http://sqlpro.developpez.com/TransactSQL/SQL_MSTransactSQL.html
Alain ROUILLON
T'as déjà entendu parler de contrainte client ou bien tu développes toujours dans ton coin ?
Si je pose la question sur SQL Server, c'est pas pour m'entendre dire que ce n'est le top en matière de SGBDR. Comment fais-tu quand tu te retrouves face à un DG qui te dit que c'est SQL Server pour les batchs ? Tu lui dis "si t'as de la thune ya Oracle !" ???
Ce forum n'est certes pas fait pour polémiquer, mais ce genre de réponse m'exaspère. Comme toujours jusqu'à présent, j'y ai trouvé des réponses de qualité, présentées par des gens professionnels. Pas par des amateurs, des adeptes de la bidouille.
"TestMan" a écrit dans le message news: 408aa007$0$22859$
Franchement SQL Server, c'est pas vraiment top comme SGBD. Si t'as de la thune, ya Oracle !
Sinon, t'as la maintenant célèbre Firebird http://firebird.sourceforge.net/
Elle fait tout même le café :) Et à un drivers JDBC type4 nickel !
A+
TM
Alain ROUILLON wrote:
Bonjour à tous,
Mon problème est le suivant :
Je disose de composants J2EE (servlets et EJB, tout le tralala). On me demande d'étudier la possibilité d'interfacer tout ce joli monde avec une
base de données SQL Server.
Y-a-t-il des possibilités pour qu'une procédure stockée sur sql server appelle une servlet par exemple ?
Merci d'avance pour les réponses,
Alain
T'as déjà entendu parler de contrainte client ou bien tu développes toujours
dans ton coin ?
Si je pose la question sur SQL Server, c'est pas pour m'entendre dire que ce
n'est le top en matière de SGBDR. Comment fais-tu quand tu te retrouves face
à un DG qui te dit que c'est SQL Server pour les batchs ? Tu lui dis "si
t'as de la thune ya Oracle !" ???
Ce forum n'est certes pas fait pour polémiquer, mais ce genre de réponse
m'exaspère. Comme toujours jusqu'à présent, j'y ai trouvé des réponses de
qualité, présentées par des gens professionnels. Pas par des amateurs, des
adeptes de la bidouille.
"TestMan" <test@example.com> a écrit dans le message news:
408aa007$0$22859$626a14ce@news.free.fr...
Franchement SQL Server, c'est pas vraiment top comme SGBD.
Si t'as de la thune, ya Oracle !
Sinon, t'as la maintenant célèbre Firebird
http://firebird.sourceforge.net/
Elle fait tout même le café :)
Et à un drivers JDBC type4 nickel !
A+
TM
Alain ROUILLON wrote:
Bonjour à tous,
Mon problème est le suivant :
Je disose de composants J2EE (servlets et EJB, tout le tralala). On me
demande d'étudier la possibilité d'interfacer tout ce joli monde avec
une
base de données SQL Server.
Y-a-t-il des possibilités pour qu'une procédure stockée sur sql server
appelle une servlet par exemple ?
T'as déjà entendu parler de contrainte client ou bien tu développes toujours dans ton coin ?
Si je pose la question sur SQL Server, c'est pas pour m'entendre dire que ce n'est le top en matière de SGBDR. Comment fais-tu quand tu te retrouves face à un DG qui te dit que c'est SQL Server pour les batchs ? Tu lui dis "si t'as de la thune ya Oracle !" ???
Ce forum n'est certes pas fait pour polémiquer, mais ce genre de réponse m'exaspère. Comme toujours jusqu'à présent, j'y ai trouvé des réponses de qualité, présentées par des gens professionnels. Pas par des amateurs, des adeptes de la bidouille.
"TestMan" a écrit dans le message news: 408aa007$0$22859$
Franchement SQL Server, c'est pas vraiment top comme SGBD. Si t'as de la thune, ya Oracle !
Sinon, t'as la maintenant célèbre Firebird http://firebird.sourceforge.net/
Elle fait tout même le café :) Et à un drivers JDBC type4 nickel !
A+
TM
Alain ROUILLON wrote:
Bonjour à tous,
Mon problème est le suivant :
Je disose de composants J2EE (servlets et EJB, tout le tralala). On me demande d'étudier la possibilité d'interfacer tout ce joli monde avec une
base de données SQL Server.
Y-a-t-il des possibilités pour qu'une procédure stockée sur sql server appelle une servlet par exemple ?
Merci d'avance pour les réponses,
Alain
Franck Andriano
Bonjour,
T'as déjà entendu parler de contrainte client ou bien tu développes toujours dans ton coin ?
Si je pose la question sur SQL Server, c'est pas pour m'entendre dire que ce n'est le top en matière de SGBDR. Comment fais-tu quand tu te retrouves face à un DG qui te dit que c'est SQL Server pour les batchs ? Tu lui dis "si t'as de la thune ya Oracle !" ???
Ce forum n'est certes pas fait pour polémiquer, mais ce genre de réponse m'exaspère. Comme toujours jusqu'à présent, j'y ai trouvé des réponses de qualité, présentées par des gens professionnels. Pas par des amateurs, des adeptes de la bidouille.
Ok, mais j'ai (on a) toujours eu des galères avec SQlServer contrairement à d'autres SGBDR : - installe d'un dbspace sur une base existante - le journal des erreurs (qui bouffe un max de ressources) - format des dates (sqlserver français, base paramétrée en anglais au niveau des dates, prenant des datetime en américain!) - curseur (lock, la gestion est galère!) - etc...
Bref, la prochaine fois j'installe une micro base chez le client!
/Franck Andriano
-- !
Bonjour,
T'as déjà entendu parler de contrainte client ou bien tu développes toujours
dans ton coin ?
Si je pose la question sur SQL Server, c'est pas pour m'entendre dire que ce
n'est le top en matière de SGBDR. Comment fais-tu quand tu te retrouves face
à un DG qui te dit que c'est SQL Server pour les batchs ? Tu lui dis "si
t'as de la thune ya Oracle !" ???
Ce forum n'est certes pas fait pour polémiquer, mais ce genre de réponse
m'exaspère. Comme toujours jusqu'à présent, j'y ai trouvé des réponses de
qualité, présentées par des gens professionnels. Pas par des amateurs, des
adeptes de la bidouille.
Ok, mais j'ai (on a) toujours eu des galères avec SQlServer contrairement à d'autres SGBDR :
- installe d'un dbspace sur une base existante
- le journal des erreurs (qui bouffe un max de ressources)
- format des dates (sqlserver français, base paramétrée en anglais au niveau des dates, prenant des datetime en américain!)
- curseur (lock, la gestion est galère!)
- etc...
Bref, la prochaine fois j'installe une micro base chez le client!
T'as déjà entendu parler de contrainte client ou bien tu développes toujours dans ton coin ?
Si je pose la question sur SQL Server, c'est pas pour m'entendre dire que ce n'est le top en matière de SGBDR. Comment fais-tu quand tu te retrouves face à un DG qui te dit que c'est SQL Server pour les batchs ? Tu lui dis "si t'as de la thune ya Oracle !" ???
Ce forum n'est certes pas fait pour polémiquer, mais ce genre de réponse m'exaspère. Comme toujours jusqu'à présent, j'y ai trouvé des réponses de qualité, présentées par des gens professionnels. Pas par des amateurs, des adeptes de la bidouille.
Ok, mais j'ai (on a) toujours eu des galères avec SQlServer contrairement à d'autres SGBDR : - installe d'un dbspace sur une base existante - le journal des erreurs (qui bouffe un max de ressources) - format des dates (sqlserver français, base paramétrée en anglais au niveau des dates, prenant des datetime en américain!) - curseur (lock, la gestion est galère!) - etc...
Bref, la prochaine fois j'installe une micro base chez le client!
/Franck Andriano
-- !
Alain ROUILLON
Effectivement SQL Server n'est vraiment pas la panacée...
Mais on constate que dans beaucoup d'entreprises, les postes à responsabilité sont occupés par des vieux de la vieille qui entravent que dalle. Et ils se rabattent systématiquement sur des solutions bateau, même si d'une part elles s'avèrent être complètement dépassées et d'autre part n'ofrent pas vraiment le meilleur rapport qualité/prix.
Mais notre métier est de trouver des solutions pour contourner cela, si on veut continuer à exister en tant que prestataire ou consultant.
Moi j'ai contourné le problème en imposant de traiter les batchs sous forme d'EJB (traitement déportés sur le serveur d'application), SQL Server ne faisant plus qu'office de vulgaire entrepot de données.
Exit le problème !!!
"Franck Andriano" a écrit dans le message news: c6j2t9$qe7$
Bonjour,
T'as déjà entendu parler de contrainte client ou bien tu développes toujours
dans ton coin ?
Si je pose la question sur SQL Server, c'est pas pour m'entendre dire que ce
n'est le top en matière de SGBDR. Comment fais-tu quand tu te retrouves face
à un DG qui te dit que c'est SQL Server pour les batchs ? Tu lui dis "si t'as de la thune ya Oracle !" ???
Ce forum n'est certes pas fait pour polémiquer, mais ce genre de réponse m'exaspère. Comme toujours jusqu'à présent, j'y ai trouvé des réponses de
qualité, présentées par des gens professionnels. Pas par des amateurs, des
adeptes de la bidouille.
Ok, mais j'ai (on a) toujours eu des galères avec SQlServer contrairement à d'autres SGBDR :
- installe d'un dbspace sur une base existante - le journal des erreurs (qui bouffe un max de ressources) - format des dates (sqlserver français, base paramétrée en anglais au niveau des dates, prenant des datetime en américain!)
- curseur (lock, la gestion est galère!) - etc...
Bref, la prochaine fois j'installe une micro base chez le client!
/Franck Andriano
-- !
Effectivement SQL Server n'est vraiment pas la panacée...
Mais on constate que dans beaucoup d'entreprises, les postes à
responsabilité sont occupés par des vieux de la vieille qui entravent que
dalle. Et ils se rabattent systématiquement sur des solutions bateau, même
si d'une part elles s'avèrent être complètement dépassées et d'autre part
n'ofrent pas vraiment le meilleur rapport qualité/prix.
Mais notre métier est de trouver des solutions pour contourner cela, si on
veut continuer à exister en tant que prestataire ou consultant.
Moi j'ai contourné le problème en imposant de traiter les batchs sous forme
d'EJB (traitement déportés sur le serveur d'application), SQL Server ne
faisant plus qu'office de vulgaire entrepot de données.
Exit le problème !!!
"Franck Andriano" <franck.andriano@clg.fr> a écrit dans le message news:
c6j2t9$qe7$1@s1.read.news.oleane.net...
Bonjour,
T'as déjà entendu parler de contrainte client ou bien tu développes
toujours
dans ton coin ?
Si je pose la question sur SQL Server, c'est pas pour m'entendre dire
que ce
n'est le top en matière de SGBDR. Comment fais-tu quand tu te retrouves
face
à un DG qui te dit que c'est SQL Server pour les batchs ? Tu lui dis "si
t'as de la thune ya Oracle !" ???
Ce forum n'est certes pas fait pour polémiquer, mais ce genre de réponse
m'exaspère. Comme toujours jusqu'à présent, j'y ai trouvé des réponses
de
qualité, présentées par des gens professionnels. Pas par des amateurs,
des
adeptes de la bidouille.
Ok, mais j'ai (on a) toujours eu des galères avec SQlServer contrairement
à d'autres SGBDR :
- installe d'un dbspace sur une base existante
- le journal des erreurs (qui bouffe un max de ressources)
- format des dates (sqlserver français, base paramétrée en anglais au
niveau des dates, prenant des datetime en américain!)
- curseur (lock, la gestion est galère!)
- etc...
Bref, la prochaine fois j'installe une micro base chez le client!
Effectivement SQL Server n'est vraiment pas la panacée...
Mais on constate que dans beaucoup d'entreprises, les postes à responsabilité sont occupés par des vieux de la vieille qui entravent que dalle. Et ils se rabattent systématiquement sur des solutions bateau, même si d'une part elles s'avèrent être complètement dépassées et d'autre part n'ofrent pas vraiment le meilleur rapport qualité/prix.
Mais notre métier est de trouver des solutions pour contourner cela, si on veut continuer à exister en tant que prestataire ou consultant.
Moi j'ai contourné le problème en imposant de traiter les batchs sous forme d'EJB (traitement déportés sur le serveur d'application), SQL Server ne faisant plus qu'office de vulgaire entrepot de données.
Exit le problème !!!
"Franck Andriano" a écrit dans le message news: c6j2t9$qe7$
Bonjour,
T'as déjà entendu parler de contrainte client ou bien tu développes toujours
dans ton coin ?
Si je pose la question sur SQL Server, c'est pas pour m'entendre dire que ce
n'est le top en matière de SGBDR. Comment fais-tu quand tu te retrouves face
à un DG qui te dit que c'est SQL Server pour les batchs ? Tu lui dis "si t'as de la thune ya Oracle !" ???
Ce forum n'est certes pas fait pour polémiquer, mais ce genre de réponse m'exaspère. Comme toujours jusqu'à présent, j'y ai trouvé des réponses de
qualité, présentées par des gens professionnels. Pas par des amateurs, des
adeptes de la bidouille.
Ok, mais j'ai (on a) toujours eu des galères avec SQlServer contrairement à d'autres SGBDR :
- installe d'un dbspace sur une base existante - le journal des erreurs (qui bouffe un max de ressources) - format des dates (sqlserver français, base paramétrée en anglais au niveau des dates, prenant des datetime en américain!)
- curseur (lock, la gestion est galère!) - etc...
Bref, la prochaine fois j'installe une micro base chez le client!
/Franck Andriano
-- !
jerome moliere
Alain ROUILLON wrote:
Bonjour à tous,
Mon problème est le suivant :
Je disose de composants J2EE (servlets et EJB, tout le tralala). On me demande d'étudier la possibilité d'interfacer tout ce joli monde avec une base de données SQL Server.
Y-a-t-il des possibilités pour qu'une procédure stockée sur sql server appelle une servlet par exemple ?
là cela me paraît de la science fiction.. désolé.. une proc stock n'a selon moi d'interet que d'accomplir des taches de mise à jour, controle de la data stockée dans un SGBDR..de là à en faire un élément clé de ta logique applicative... pkoi ne pas envisager plutot le scenario où c'est depuis une servlet qu'il y a invocation de la proc stock par JDBC puis retour à la servlet et forward vers une autre servlet ?
Navré Jerome
-- Auteur cahier du programmeur Java tome 2 - Eyrolles 10/2003 http://www.eyrolles.com/php.informatique/Ouvrages/ouvrage.php3?ouv_ean1382212111941
Alain ROUILLON wrote:
Bonjour à tous,
Mon problème est le suivant :
Je disose de composants J2EE (servlets et EJB, tout le tralala). On me
demande d'étudier la possibilité d'interfacer tout ce joli monde avec une
base de données SQL Server.
Y-a-t-il des possibilités pour qu'une procédure stockée sur sql server
appelle une servlet par exemple ?
là cela me paraît de la science fiction.. désolé..
une proc stock n'a selon moi d'interet que d'accomplir des taches
de mise à jour, controle de la data stockée dans un SGBDR..de là à en
faire un élément clé de ta logique applicative...
pkoi ne pas envisager plutot le scenario où c'est depuis une servlet
qu'il y a invocation de la proc stock par JDBC puis retour à la servlet
et forward vers une autre servlet ?
Navré
Jerome
--
Auteur cahier du programmeur Java tome 2 - Eyrolles 10/2003
http://www.eyrolles.com/php.informatique/Ouvrages/ouvrage.php3?ouv_ean1382212111941
Je disose de composants J2EE (servlets et EJB, tout le tralala). On me demande d'étudier la possibilité d'interfacer tout ce joli monde avec une base de données SQL Server.
Y-a-t-il des possibilités pour qu'une procédure stockée sur sql server appelle une servlet par exemple ?
là cela me paraît de la science fiction.. désolé.. une proc stock n'a selon moi d'interet que d'accomplir des taches de mise à jour, controle de la data stockée dans un SGBDR..de là à en faire un élément clé de ta logique applicative... pkoi ne pas envisager plutot le scenario où c'est depuis une servlet qu'il y a invocation de la proc stock par JDBC puis retour à la servlet et forward vers une autre servlet ?
Navré Jerome
-- Auteur cahier du programmeur Java tome 2 - Eyrolles 10/2003 http://www.eyrolles.com/php.informatique/Ouvrages/ouvrage.php3?ouv_ean1382212111941
aldeponk
Merci pour ta réponse.
L'origine de la question se trouve dans le fait que jusqu'à présent mes batchs sont des procédures stockées.
En déplaçant le problème avec l'utilisation d'EJB en charge des traitements (s'appuyant sur JDO éventuellement) je résoud le problème. Mes batchs sont des EJB et le sgbdr ne joue que le rôle d'entrepot de données.
Alain
"jerome moliere" a écrit dans le message news: c6vqmq$dtf$
Alain ROUILLON wrote:
Bonjour à tous,
Mon problème est le suivant :
Je disose de composants J2EE (servlets et EJB, tout le tralala). On me demande d'étudier la possibilité d'interfacer tout ce joli monde avec une
base de données SQL Server.
Y-a-t-il des possibilités pour qu'une procédure stockée sur sql server appelle une servlet par exemple ?
là cela me paraît de la science fiction.. désolé.. une proc stock n'a selon moi d'interet que d'accomplir des taches de mise à jour, controle de la data stockée dans un SGBDR..de là à en faire un élément clé de ta logique applicative... pkoi ne pas envisager plutot le scenario où c'est depuis une servlet qu'il y a invocation de la proc stock par JDBC puis retour à la servlet et forward vers une autre servlet ?
Navré Jerome
-- Auteur cahier du programmeur Java tome 2 - Eyrolles 10/2003
L'origine de la question se trouve dans le fait que jusqu'à présent mes
batchs sont des procédures stockées.
En déplaçant le problème avec l'utilisation d'EJB en charge des traitements
(s'appuyant sur JDO éventuellement) je résoud le problème. Mes batchs sont
des EJB et le sgbdr ne joue que le rôle d'entrepot de données.
Alain
"jerome moliere" <jmoliere@nerim.net> a écrit dans le message news:
c6vqmq$dtf$1@biggoron.nerim.net...
Alain ROUILLON wrote:
Bonjour à tous,
Mon problème est le suivant :
Je disose de composants J2EE (servlets et EJB, tout le tralala). On me
demande d'étudier la possibilité d'interfacer tout ce joli monde avec
une
base de données SQL Server.
Y-a-t-il des possibilités pour qu'une procédure stockée sur sql server
appelle une servlet par exemple ?
là cela me paraît de la science fiction.. désolé..
une proc stock n'a selon moi d'interet que d'accomplir des taches
de mise à jour, controle de la data stockée dans un SGBDR..de là à en
faire un élément clé de ta logique applicative...
pkoi ne pas envisager plutot le scenario où c'est depuis une servlet
qu'il y a invocation de la proc stock par JDBC puis retour à la servlet
et forward vers une autre servlet ?
Navré
Jerome
--
Auteur cahier du programmeur Java tome 2 - Eyrolles 10/2003
L'origine de la question se trouve dans le fait que jusqu'à présent mes batchs sont des procédures stockées.
En déplaçant le problème avec l'utilisation d'EJB en charge des traitements (s'appuyant sur JDO éventuellement) je résoud le problème. Mes batchs sont des EJB et le sgbdr ne joue que le rôle d'entrepot de données.
Alain
"jerome moliere" a écrit dans le message news: c6vqmq$dtf$
Alain ROUILLON wrote:
Bonjour à tous,
Mon problème est le suivant :
Je disose de composants J2EE (servlets et EJB, tout le tralala). On me demande d'étudier la possibilité d'interfacer tout ce joli monde avec une
base de données SQL Server.
Y-a-t-il des possibilités pour qu'une procédure stockée sur sql server appelle une servlet par exemple ?
là cela me paraît de la science fiction.. désolé.. une proc stock n'a selon moi d'interet que d'accomplir des taches de mise à jour, controle de la data stockée dans un SGBDR..de là à en faire un élément clé de ta logique applicative... pkoi ne pas envisager plutot le scenario où c'est depuis une servlet qu'il y a invocation de la proc stock par JDBC puis retour à la servlet et forward vers une autre servlet ?
Navré Jerome
-- Auteur cahier du programmeur Java tome 2 - Eyrolles 10/2003
