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
Daniel
Le 22/06/2011 12:04, Stéphane Miqueu a écrit :
Bonjour,
Changement de boulot, j'avais du abandonner Windev pour passer sur Visual Studio .NET afin de maintenir l'existant.
Aujourd'hui, une opportunité va se présenter qui me permettrait de revenir vers Windev.
Juste quelques questions (un état des lieux rapide) :
1. Pour des liens avec SQLServeur, quelles sont vos préconisations entre le module natif (payant) et les accès [alter]natif s'ils existent toujours.
les accès alternatifs existent toujours. Je pense que les accès alternatifs sont mieux conçus, et permettent de faire évoluer indépendamment les versions windev et des versions SGBD.
2. Quid d'un lien avec une base FireBird 1.5 allant évoluer vers la 2.1
N'utilisant plus firebird, je ne sais pas. Mais vous pouvez reprendre le source de l'accès et le faire évoluer.
3. Pour les développement futur (40 postes) quels base choisir ?
Tout dépend des compétences, de l'environnement etc...
SI vous êtes compétents sous SQLserver, rester sous SQLserver. Sinon je pense que POstgresql est une bonne alternative gratuite.
Changement de boulot, j'avais du abandonner Windev pour passer sur
Visual Studio .NET afin de maintenir l'existant.
Aujourd'hui, une opportunité va se présenter qui me permettrait de
revenir vers Windev.
Juste quelques questions (un état des lieux rapide) :
1. Pour des liens avec SQLServeur, quelles sont vos préconisations entre
le module natif (payant) et les accès [alter]natif s'ils existent toujours.
les accès alternatifs existent toujours. Je pense que les accès
alternatifs sont mieux conçus, et permettent de faire évoluer
indépendamment les versions windev et des versions SGBD.
2. Quid d'un lien avec une base FireBird 1.5 allant évoluer vers la 2.1
N'utilisant plus firebird, je ne sais pas. Mais vous pouvez reprendre le
source de l'accès et le faire évoluer.
3. Pour les développement futur (40 postes) quels base choisir ?
Tout dépend des compétences, de l'environnement etc...
SI vous êtes compétents sous SQLserver, rester sous SQLserver. Sinon je
pense que POstgresql est une bonne alternative gratuite.
Merci de vos réponses.
--
suivre ce lien pour répondre:
http://cerbermail.com/?2KrV3YZXnn
Daniel
;-)
Changement de boulot, j'avais du abandonner Windev pour passer sur Visual Studio .NET afin de maintenir l'existant.
Aujourd'hui, une opportunité va se présenter qui me permettrait de revenir vers Windev.
Juste quelques questions (un état des lieux rapide) :
1. Pour des liens avec SQLServeur, quelles sont vos préconisations entre le module natif (payant) et les accès [alter]natif s'ils existent toujours.
les accès alternatifs existent toujours. Je pense que les accès alternatifs sont mieux conçus, et permettent de faire évoluer indépendamment les versions windev et des versions SGBD.
2. Quid d'un lien avec une base FireBird 1.5 allant évoluer vers la 2.1
N'utilisant plus firebird, je ne sais pas. Mais vous pouvez reprendre le source de l'accès et le faire évoluer.
3. Pour les développement futur (40 postes) quels base choisir ?
Tout dépend des compétences, de l'environnement etc...
SI vous êtes compétents sous SQLserver, rester sous SQLserver. Sinon je pense que POstgresql est une bonne alternative gratuite.
Changement de boulot, j'avais du abandonner Windev pour passer sur Visual Studio .NET afin de maintenir l'existant.
Aujourd'hui, une opportunité va se présenter qui me permettrait de revenir vers Windev.
Juste quelques questions (un état des lieux rapide) :
1. Pour des liens avec SQLServeur, quelles sont vos préconisations entre le module natif (payant) et les accès [alter]natif s'ils existent toujours.
2. Quid d'un lien avec une base FireBird 1.5 allant évoluer vers la 2.1
3. Pour les développement futur (40 postes) quels base choisir ?
Merci de vos réponses.
Salut Stéphane :) Daniel étant toujours de bon conseil, je n'en rajouterai pas, mon statut dans ce cas est 'Utilisateur'. J'ai toujours des projets avec mysql, mais, je préfère postgresql. Je pense que les acces [alter]natifs offrent une plus grande souplesse, notamment au niveau des constructions de requètes. Avec un simple frontal comme Pgadmin3, tu peux "jouer" tes requètes à volonté. Il te suffit de les intégrer dans le code et le tour est joué. J'ai souvent vu la commande RequèteSansCorrection être utilisée parce que windev modifiait les requètes.
à bientôt Si tu as besoin de bouts de code, n'hésite pas ! A+
Stéphane Miqueu a formulé ce mercredi :
Bonjour,
Changement de boulot, j'avais du abandonner Windev pour passer sur Visual
Studio .NET afin de maintenir l'existant.
Aujourd'hui, une opportunité va se présenter qui me permettrait de revenir
vers Windev.
Juste quelques questions (un état des lieux rapide) :
1. Pour des liens avec SQLServeur, quelles sont vos préconisations entre le
module natif (payant) et les accès [alter]natif s'ils existent toujours.
2. Quid d'un lien avec une base FireBird 1.5 allant évoluer vers la 2.1
3. Pour les développement futur (40 postes) quels base choisir ?
Merci de vos réponses.
Salut Stéphane :)
Daniel étant toujours de bon conseil, je n'en rajouterai pas, mon
statut dans ce cas est 'Utilisateur'.
J'ai toujours des projets avec mysql, mais, je préfère postgresql.
Je pense que les acces [alter]natifs offrent une plus grande souplesse,
notamment au niveau des constructions de requètes. Avec un simple
frontal comme Pgadmin3, tu peux "jouer" tes requètes à volonté. Il te
suffit de les intégrer dans le code et le tour est joué.
J'ai souvent vu la commande RequèteSansCorrection être utilisée parce
que windev modifiait les requètes.
à bientôt
Si tu as besoin de bouts de code, n'hésite pas !
A+
Changement de boulot, j'avais du abandonner Windev pour passer sur Visual Studio .NET afin de maintenir l'existant.
Aujourd'hui, une opportunité va se présenter qui me permettrait de revenir vers Windev.
Juste quelques questions (un état des lieux rapide) :
1. Pour des liens avec SQLServeur, quelles sont vos préconisations entre le module natif (payant) et les accès [alter]natif s'ils existent toujours.
2. Quid d'un lien avec une base FireBird 1.5 allant évoluer vers la 2.1
3. Pour les développement futur (40 postes) quels base choisir ?
Merci de vos réponses.
Salut Stéphane :) Daniel étant toujours de bon conseil, je n'en rajouterai pas, mon statut dans ce cas est 'Utilisateur'. J'ai toujours des projets avec mysql, mais, je préfère postgresql. Je pense que les acces [alter]natifs offrent une plus grande souplesse, notamment au niveau des constructions de requètes. Avec un simple frontal comme Pgadmin3, tu peux "jouer" tes requètes à volonté. Il te suffit de les intégrer dans le code et le tour est joué. J'ai souvent vu la commande RequèteSansCorrection être utilisée parce que windev modifiait les requètes.
à bientôt Si tu as besoin de bouts de code, n'hésite pas ! A+
patrice
Le 22/06/2011 12:04, Stéphane Miqueu a écrit :
Bonjour,
Changement de boulot, j'avais du abandonner Windev pour passer sur Visual Studio .NET afin de maintenir l'existant.
Aujourd'hui, une opportunité va se présenter qui me permettrait de revenir vers Windev.
Juste quelques questions (un état des lieux rapide) :
1. Pour des liens avec SQLServeur, quelles sont vos préconisations entre le module natif (payant) et les accès [alter]natif s'ils existent toujours.
2. Quid d'un lien avec une base FireBird 1.5 allant évoluer vers la 2.1
3. Pour les développement futur (40 postes) quels base choisir ?
Merci de vos réponses.
le seul interet de l'acces natif est l'écranversfichier et vice versa Pour tout le reste, je construit les requetes sql à la main sinon tu peut rien controler
Le 22/06/2011 12:04, Stéphane Miqueu a écrit :
Bonjour,
Changement de boulot, j'avais du abandonner Windev pour passer sur
Visual Studio .NET afin de maintenir l'existant.
Aujourd'hui, une opportunité va se présenter qui me permettrait de
revenir vers Windev.
Juste quelques questions (un état des lieux rapide) :
1. Pour des liens avec SQLServeur, quelles sont vos préconisations entre
le module natif (payant) et les accès [alter]natif s'ils existent toujours.
2. Quid d'un lien avec une base FireBird 1.5 allant évoluer vers la 2.1
3. Pour les développement futur (40 postes) quels base choisir ?
Merci de vos réponses.
le seul interet de l'acces natif est l'écranversfichier et vice versa
Pour tout le reste, je construit les requetes sql à la main sinon tu
peut rien controler
Changement de boulot, j'avais du abandonner Windev pour passer sur Visual Studio .NET afin de maintenir l'existant.
Aujourd'hui, une opportunité va se présenter qui me permettrait de revenir vers Windev.
Juste quelques questions (un état des lieux rapide) :
1. Pour des liens avec SQLServeur, quelles sont vos préconisations entre le module natif (payant) et les accès [alter]natif s'ils existent toujours.
2. Quid d'un lien avec une base FireBird 1.5 allant évoluer vers la 2.1
3. Pour les développement futur (40 postes) quels base choisir ?
Merci de vos réponses.
le seul interet de l'acces natif est l'écranversfichier et vice versa Pour tout le reste, je construit les requetes sql à la main sinon tu peut rien controler
JeAn-PhI
patrice avait écrit le 26/06/2011 :
Le 22/06/2011 12:04, Stéphane Miqueu a écrit :
Bonjour,
Changement de boulot, j'avais du abandonner Windev pour passer sur Visual Studio .NET afin de maintenir l'existant.
Aujourd'hui, une opportunité va se présenter qui me permettrait de revenir vers Windev.
Juste quelques questions (un état des lieux rapide) :
1. Pour des liens avec SQLServeur, quelles sont vos préconisations entre le module natif (payant) et les accès [alter]natif s'ils existent toujours.
2. Quid d'un lien avec une base FireBird 1.5 allant évoluer vers la 2.1
3. Pour les développement futur (40 postes) quels base choisir ?
Merci de vos réponses.
le seul interet de l'acces natif est l'écranversfichier et vice versa Pour tout le reste, je construit les requetes sql à la main sinon tu peut rien controler
la même fonction existe avec les accès alternatif
-- Cordialement JeAn-PhI
patrice avait écrit le 26/06/2011 :
Le 22/06/2011 12:04, Stéphane Miqueu a écrit :
Bonjour,
Changement de boulot, j'avais du abandonner Windev pour passer sur
Visual Studio .NET afin de maintenir l'existant.
Aujourd'hui, une opportunité va se présenter qui me permettrait de
revenir vers Windev.
Juste quelques questions (un état des lieux rapide) :
1. Pour des liens avec SQLServeur, quelles sont vos préconisations entre
le module natif (payant) et les accès [alter]natif s'ils existent toujours.
2. Quid d'un lien avec une base FireBird 1.5 allant évoluer vers la 2.1
3. Pour les développement futur (40 postes) quels base choisir ?
Merci de vos réponses.
le seul interet de l'acces natif est l'écranversfichier et vice versa
Pour tout le reste, je construit les requetes sql à la main sinon tu peut
rien controler
Changement de boulot, j'avais du abandonner Windev pour passer sur Visual Studio .NET afin de maintenir l'existant.
Aujourd'hui, une opportunité va se présenter qui me permettrait de revenir vers Windev.
Juste quelques questions (un état des lieux rapide) :
1. Pour des liens avec SQLServeur, quelles sont vos préconisations entre le module natif (payant) et les accès [alter]natif s'ils existent toujours.
2. Quid d'un lien avec une base FireBird 1.5 allant évoluer vers la 2.1
3. Pour les développement futur (40 postes) quels base choisir ?
Merci de vos réponses.
le seul interet de l'acces natif est l'écranversfichier et vice versa Pour tout le reste, je construit les requetes sql à la main sinon tu peut rien controler
la même fonction existe avec les accès alternatif
-- Cordialement JeAn-PhI
Alex
Bonjour,
Ici on a SQL Serveur (2000) ,une centaine d'utilisateurs ,connecteur OLEDB avec ordres SQLxxx (encapsulés dans une classe), pas de pb de perf (pas testé l’accès alternatif).
Cordialement
Alex
Bonjour,
Ici on a SQL Serveur (2000)
,une centaine d'utilisateurs
,connecteur OLEDB avec ordres SQLxxx (encapsulés dans une classe), pas
de pb de perf (pas testé laccès alternatif).
Ici on a SQL Serveur (2000) ,une centaine d'utilisateurs ,connecteur OLEDB avec ordres SQLxxx (encapsulés dans une classe), pas de pb de perf (pas testé l’accès alternatif).
Cordialement
Alex
Alex
Bonjour,
Ici on a une application principale d'une centaine d'utilisateurs, SQL Serveur 2000 / ODBC et OLEDB / ordres SQLxxx, ça marche très bien. On avait commencé en ODBC, puis on a testé OLEDB : c'est encore mieux (pas besoin de créer des sources de données ODBC sur les postes clients). On a aussi des traitements de transfert de données entre bases qui passent plusieurs fois par jour : MySQL (ODBC) -> SQL Serveur (OLEDB). Toute la partie SQL (ordres SQLxxx) est dans une classe et fonctionne aussi bien sur SQL Serveur que sur MySQL, ex. :
r1 est un cReq sReq est une chaine = [ select .... ]
// Lit données MySQL SI cReqCx::gbChange(sCxMySql) ALORS TANTQUE r1:mbAvance(sReq) oG2 est un strG2 oG2:s1=r1:C[1] ..... oG2:s5=r1:C[5] oG2:s6=r1:C[6] TableauAjoute(tG2, oG2) FIN FIN
// Mises à jour dans SQL Serveur SI cReqCx::gbChange(sCxSqlServeur) ALORS POUR TOUT oG2 DE tG2 sReq = "update ... " SI r1:mbExecute(sReq) ALORS ..... FIN FIN FIN
Concernant les accès alternatifs, petite question sur la pérennité : -PHP4WD est maintenable par nous (http windev+script php ouvert) : OK -Pour les autres accès, ceux basés sur des DLL (code fermé ?), que arrive-t-il si le développeur a un accident ? (on ne lui souhaite pas évidemment, mais on doit penser à la pérennit é de nos projets) On va étudier PHP4WD pour peut-être faire du MySQL par HTTP à partir de téléphones Android. Dans tous les cas bravo à Firetox, qui fait un super boulot.
Alex
Bonjour,
Ici on a une application principale d'une centaine d'utilisateurs,
SQL Serveur 2000 / ODBC et OLEDB / ordres SQLxxx, ça marche très bien.
On avait commencé en ODBC, puis on a testé OLEDB : c'est encore mieux
(pas besoin de créer des sources de données ODBC sur les postes
clients).
On a aussi des traitements de transfert de données entre bases qui
passent plusieurs fois par jour : MySQL (ODBC) -> SQL Serveur (OLEDB).
Toute la partie SQL (ordres SQLxxx) est dans une classe et fonctionne
aussi bien sur SQL Serveur que sur MySQL, ex. :
r1 est un cReq
sReq est une chaine = [
select ....
]
// Lit données MySQL
SI cReqCx::gbChange(sCxMySql) ALORS
TANTQUE r1:mbAvance(sReq)
oG2 est un strG2
oG2:s1=r1:C[1]
.....
oG2:s5=r1:C[5]
oG2:s6=r1:C[6]
TableauAjoute(tG2, oG2)
FIN
FIN
// Mises à jour dans SQL Serveur
SI cReqCx::gbChange(sCxSqlServeur) ALORS
POUR TOUT oG2 DE tG2
sReq = "update ... "
SI r1:mbExecute(sReq) ALORS
.....
FIN
FIN
FIN
Concernant les accès alternatifs, petite question sur la pérennité :
-PHP4WD est maintenable par nous (http windev+script php ouvert) : OK
-Pour les autres accès, ceux basés sur des DLL (code fermé ?), que
arrive-t-il si le développeur a un accident ?
(on ne lui souhaite pas évidemment, mais on doit penser à la pérennit é
de nos projets)
On va étudier PHP4WD pour peut-être faire du MySQL par HTTP à partir
de téléphones Android.
Dans tous les cas bravo à Firetox, qui fait un super boulot.
Ici on a une application principale d'une centaine d'utilisateurs, SQL Serveur 2000 / ODBC et OLEDB / ordres SQLxxx, ça marche très bien. On avait commencé en ODBC, puis on a testé OLEDB : c'est encore mieux (pas besoin de créer des sources de données ODBC sur les postes clients). On a aussi des traitements de transfert de données entre bases qui passent plusieurs fois par jour : MySQL (ODBC) -> SQL Serveur (OLEDB). Toute la partie SQL (ordres SQLxxx) est dans une classe et fonctionne aussi bien sur SQL Serveur que sur MySQL, ex. :
r1 est un cReq sReq est une chaine = [ select .... ]
// Lit données MySQL SI cReqCx::gbChange(sCxMySql) ALORS TANTQUE r1:mbAvance(sReq) oG2 est un strG2 oG2:s1=r1:C[1] ..... oG2:s5=r1:C[5] oG2:s6=r1:C[6] TableauAjoute(tG2, oG2) FIN FIN
// Mises à jour dans SQL Serveur SI cReqCx::gbChange(sCxSqlServeur) ALORS POUR TOUT oG2 DE tG2 sReq = "update ... " SI r1:mbExecute(sReq) ALORS ..... FIN FIN FIN
Concernant les accès alternatifs, petite question sur la pérennité : -PHP4WD est maintenable par nous (http windev+script php ouvert) : OK -Pour les autres accès, ceux basés sur des DLL (code fermé ?), que arrive-t-il si le développeur a un accident ? (on ne lui souhaite pas évidemment, mais on doit penser à la pérennit é de nos projets) On va étudier PHP4WD pour peut-être faire du MySQL par HTTP à partir de téléphones Android. Dans tous les cas bravo à Firetox, qui fait un super boulot.
Alex
Firetox
Bonjour,
les dll des acces alter natif sont fournies avec leur source visual C++ donc vous avez tout pour reprendre le cas echeant pour les dll le code est aussi ouvert et open source et donc fourni
Concernant les accès alternatifs, petite question sur la pérennité : -PHP4WD est maintenable par nous (http windev+script php ouvert) : OK -Pour les autres accès, ceux basés sur des DLL (code fermé ?), que arrive-t-il si le développeur a un accident ?
(on ne lui souhaite pas évidemment, mais on doit penser à la pérennité de nos projets)
On va étudier PHP4WD pour peut-être faire du MySQL par HTTP à partir de téléphones Android. Dans tous les cas bravo à Firetox, qui fait un super boulot.
Alex
Firetox
Bonjour,
les dll des acces alter natif sont fournies avec leur source visual C++
donc vous avez tout pour reprendre le cas echeant pour les dll le code est
aussi ouvert et open source et donc fourni
Concernant les accès alternatifs, petite question sur la pérennité :
-PHP4WD est maintenable par nous (http windev+script php ouvert) : OK
-Pour les autres accès, ceux basés sur des DLL (code fermé ?), que
arrive-t-il si le développeur a un accident ?
(on ne lui souhaite pas évidemment, mais on doit penser à la pérennité
de nos projets)
On va étudier PHP4WD pour peut-être faire du MySQL par HTTP à partir
de téléphones Android.
Dans tous les cas bravo à Firetox, qui fait un super boulot.
les dll des acces alter natif sont fournies avec leur source visual C++ donc vous avez tout pour reprendre le cas echeant pour les dll le code est aussi ouvert et open source et donc fourni
Concernant les accès alternatifs, petite question sur la pérennité : -PHP4WD est maintenable par nous (http windev+script php ouvert) : OK -Pour les autres accès, ceux basés sur des DLL (code fermé ?), que arrive-t-il si le développeur a un accident ?
(on ne lui souhaite pas évidemment, mais on doit penser à la pérennité de nos projets)
On va étudier PHP4WD pour peut-être faire du MySQL par HTTP à partir de téléphones Android. Dans tous les cas bravo à Firetox, qui fait un super boulot.
Alex
Firetox
Daniel
Bonjour,
Le 29/06/2011 10:59, Alex a écrit :
Bonjour,
-Pour les autres accès, ceux basés sur des DLL (code fermé ?), que arrive-t-il si le développeur a un accident ?
le code n'est pas fermé, car le source est fourni pour les classes et pour les dll.
Plus ouvert difficile de faire.
Bien entendu si vous souhaitez modifier les accès, il faut un minimum de ressources en c et lire la doc des API sur lesquelles reposent les DLL.
