[WD16] Etat des lieux SQLServeur

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.

Merci de vos réponses.

--
suivre ce lien pour répondre:
http://cerbermail.com/?2KrV3YZXnn
Daniel
;-)

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+

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

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

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 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,

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,

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.


--
suivre ce lien pour répondre:
http://cerbermail.com/?2KrV3YZXnn
Daniel
;-)