Discussion :

[step37]

Bonjour,

Je vous communique ci après le pb, que nous estimons comme étant certainement un problème de compatibilité entre Windws et MS SQL serveur :

Nous avons une procédure stockée qui ajoute x fois des enregistrement en bdd là ou elle ne devrait n'en insérer qu'un seul (cela fais froid dans le dos car maintenant nous avons les plus grands doute quant à la capacité de Windev de nous assurez de l'intégrité des données).

La même procédure stockée lancée sous sql (2005) fonctionne parfaitement.

Voici le code nécessaire à la reproduction du problème :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
********************************************************************************************************************
-- CREATION DE LA TABLE
SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO
SET ANSI_PADDING ON
GO
CREATE TABLE [dbo].[Personnes](
[IDPersonne] [int] IDENTITY(1,1) NOT NULL,
[NomPersonne] [varchar](50) COLLATE French_CI_AS NOT NULL CONSTRAINT [DF_Personnes_NomPersonne]  DEFAULT (''),
CONSTRAINT [PK_Personnes] PRIMARY KEY CLUSTERED 
(
[IDPersonne] ASC
)WITH (PAD_INDEX  = OFF, STATISTICS_NORECOMPUTE  = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS  = ON, ALLOW_PAGE_LOCKS  = ON) ON [PRIMARY]
) ON [PRIMARY]
 
GO
SET ANSI_PADDING OFF
GO
********************************************************************************************************************
**********************************************************
-- CREATION DE LA PROCEDURE
 
set ANSI_NULLS ON
set QUOTED_IDENTIFIER ON
GO
CREATE PROCEDURE [dbo].[ProcInsertPersonne] (@Nom as varchar(50))
AS
BEGIN
Declare @IDRetour as int
 
SET @IDRetour = 0
SET NOCOUNT ON
INSERT INTO Personnes (NomPersonne) VALUES (@Nom)
SET @IDRetour = SCOPE_IDENTITY()
SELECT @IDRetour
END
GO
********************************************************************************************************************
********************************************************************************************************************
--TEST DE LA PROCEDURE
Exec ProcInsertPersonne 'codetest'
select * from Personnes where nompersonne ='toto'
delete FROM Personnes where nompersonne ='toto'
 
********************************************************************************************************************
--Suppression de la table
IF  EXISTS (SELECT * FROM sys.objects WHERE object_id = OBJECT_ID(N'[dbo].[Personnes]') AND type in (N'U'))
DROP TABLE [dbo].[Personnes]
GO
 
 
******************************************************************************************************************************************************************************
--SUPPRESSION DE LA PROCEDURE
DROP PROCEDURE [dbo].[ProcInsertPersonne][/INDENT][/INDENT][/INDENT]

Le support Technique de PCSoft nous indique comme réponse d'effectuer le changement suivant :

"Il faut pour cela intervenir sur la connexion, en ajoutant dans les <Options supplémentaires> les constantes "hCurseurServeur" et "hCurseurForwardOnly".

Exemple :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

lConnexion = HDécritConnexion ( "MaConnexion1" , "sa" , "" , "PMO" , "TEST" , hOledbSQLServer , hOLectureEcriture ,  "" , hCurseurServeur + hCurseurForwardOnly ) "

Cela fonctionne mais.... cela génère ensuite une autre erreur :

"[I]Quand je fais un hexporteXML(UneSourceDeDonnee, Chemin, hExpCréation) le code ne fonctionne pas et je rencontre une erreur :

voici le message d'erreur :

Erreur à la ligne 14 du traitement Procédure globale ConnexionBase.
Vous avez appelé la fonction HExporteXML.
Erreur de l'accès OLE DB.
Numéro d'erreur = 170123

Echec de la récupération du nombre d'enregistrements dans le fichier <>.

Informations techniques

Projet : ProjetTest

Dump de l'erreur du module <WD140HF.DLL> <14.00Dqh>.

- Appel WL :
Traitement de <Procedures globales de ProjetTest.ConnexionBase>, ligne <14>, thread <0>
Fonction <HExporteXML>, n° de syntaxe <4>

- Niveau : erreur fatale (EL_FATAL)

- Code erreur : 73001

- Code erreur WD55 : 3001

- Pas de code d'erreur système

- Pas de message d'erreur système

- Que s'est-il passé ?
Erreur de l'accès OLE DB.
Numéro d'erreur = 170123

Echec de la récupération du nombre d'enregistrements dans le fichier <>.

- Infos de debug :
IEWDOLDB=111010
Module=<WDOLDB>
Version=<14.00Ap>
Fonction (7,101)

- Infos attachées :
EIT_NATIVECODE : <170123>
EIT_LOGICALTABLENAME : <PsdMaSource>
EIT_PILEWL :
Procédure globale ConnexionBase (Procedures globales de ProjetTest.ConnexionBase), ligne 14
Clic sur btnTest (fenTest.btnTest), ligne 1
EIT_COMPOSANT :

EIT_DATEHEURE : 07/12/2009 16:10:17

- Identifiant dans le .err : 72801"

La réponse de PCsoft est la suivante :

"Dans l’immédiat, je vous conseille de créer une nouvelle connexion et d’utiliser cette connexion uniquement pour la commande HExporteXML."

Quelqu'un a-t-il été confronté à ce type de problème ????


Autre point subalterne mais pour le moin pénible : PCSoft nous engagent à passer sur l'accè natif SQL.

Pour moi deux question se posent :

1 - Accès natif ou pas, sur des informations ou fonctions non spécifiques SQL 2005/2008 les résultats en terme de donnée doivent être les mêmes, non ?

2 - L'accès natif PCSoft n'est-il pas simplement la mise en application de l'accès natif Microsoft :

http://msdn.microsoft.com/en-us/data/aa937733.aspx

Si tel est le cas, il est imcompréhensible que les utilisateur aient à payer PCSoft pour que leur produits soient aux normes et compatible avec les bases de données du marché.

Imaginez un constructeur automobile qui vous dise : ma voiture fonctionne parfaitement avec Mon essence mais si vous voulez rouler avec du "sans Plomb 98" normalisé que vous retrouvez dans toutes les stations services vous devez payer l'adaptation du moteur.....

Merci de vos informations et commentaires,

Bonne journée,

[Raptor92]

Bonjour,

Excusez ma question, mais pourquoi ne pas utiliser un lien ODBC courant, celui ci est gratuit et fonctionne très bien avec une BDD SQL Server (aussi bien 2005 que 2008).

Avec quelle version de Windev travaillez vous, pour autant, je ne pense pas qu'il y ai un problème de compatibilité entre Windows et SQL Server

Bonne après midi

[Emmanuel Lecoester]

Que donne une recherche sur l'erreur

Erreur de l'accès OLE DB.
Numéro d'erreur = 170123

?

je pense que l'accès ole-db ne supporte pas les curseurs sur serveur mais uniquement les curseur client.

De moi a vous je vois mal comment une execution de curseur coté client ou serveur peut générer x lignes dans la base...

que donne le traceur de session du coté sqlserveur ?
combien de fois est executée la procédure sqlserveur ?

[step37]

je ne pense pas qu'il y ai un problème de compatibilité entre Windows et SQL Server

Bonne après midi

Exact, il fallait lire windev et non windows. Nous n'avons pas par exemple ce type de problème sous vb 6.

Merci,

[step37]

Que donne une recherche sur l'erreur
?

Nous n'avons pu trouver d'information précise sur cette erreur.

De moi a vous je vois mal comment une execution de curseur coté client ou serveur peut générer x lignes dans la base...

Non, la mise en place des options "hCurseurServeur" et "hCurseurForwardOnly" rend l'exécution de la procédure stockée normale : Une seule ligne insérée, mais l'ordre hexporteXML génère une erreur ensuite.

Donc soit on rajoute ces paramètre et la procédure stockée fait correctement son job, mais nous avons une erreur ensuite soit nous ne mettons pas ces paramètres et la procédure stockée insère 5 lignes

combien de fois est executée la procédure sqlserveur ?

Une seule fois !

Pour ce rendre compte du problème, exécuter simplement les deux scripts que nous avons mis précédemment, l'un pour créer la table, l'autre la procédure stockée, puis exécutez une fois sous windev le code suivant :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
PsdMaSource est une Source de Données
bRetour est un booléen 
lConnexion est un entier 
sSQL est une chaîne
lConnexion = HDécritConnexion("MaConnexion1", "Login", "password", "NomServeur","BaseDeTest",hOledbSQLServer, hOLectureEcriture, "")
SI lConnexion <> 0 ALORS
       sSQL = "Exec ProcInsertPersonne 'codetest'"
       HExécuteRequêteSQL(PsdMaSource,"MaConnexion1",hRequêteSansCorrection,sSQL)
 
 
 
FIN
 
 
 
SQLDéconnecte()

Puis regardez le résultat dans la table....

PS : Dans la procédure précédente sur SQL noter à remplacer 'toto'
par 'codetest'



a+++++

[step37]

Autre point subalterne mais pour le moin pénible : PCSoft nous engagent à passer sur l'accè natif SQL.

Pour moi deux question se posent :

1 - Accès natif ou pas, sur des informations ou fonctions non spécifiques SQL 2005/2008 les résultats en terme de donnée doivent être les mêmes, non ?

2 - L'accès natif PCSoft n'est-il pas simplement la mise en application de l'accès natif Microsoft :

http://msdn.microsoft.com/en-us/data/aa937733.aspx

Si tel est le cas, il est imcompréhensible que les utilisateur aient à payer PCSoft pour que leur produits soient aux normes et compatible avec les bases de données du marché.

Imaginez un constructeur automobile qui vous dise : ma voiture fonctionne parfaitement avec Mon essence mais si vous voulez rouler avec du "sans Plomb 98" normalisé que vous retrouvez dans toutes les stations services vous devez payer l'adaptation du moteur.....

Merci de vos informations et commentaires,

Bonne journée,

Sur ce point précis tout le monde trouve cela normal ??????

En tout état de cause, les produits PCSoft ne pourrons jamais utiliser les nouvelles fonctionnalités de SQL 2005/2008 et supérieurs, si PCSoft ne délivre pas de base pour ces produits de développement les accès natifs aux bases du marché.

Les autres accès seront certainement abondonnés dans le temps.

Donc la question est réelle : doit-on systématiquement banquer pour que PCSoft fasse son job d'éditeur.

[Lo²]

Salut à toi,

Ce n'est pas pour polémiquer, mais dans le cas où il faudrait en effet avoir l'accès natif pour accèder à toutes les fonctionnalités de SQLServer, il me semble en effet "normal" de payer.

Il faut peut-être prendre en compte également que MS a peut-être fait payer PCSoft pour utiliser leurs produits.

[fucce]

Imaginez un constructeur automobile qui vous dise : ma voiture fonctionne parfaitement avec Mon essence mais si vous voulez rouler avec du "sans Plomb 98" normalisé que vous retrouvez dans toutes les stations services vous devez payer l'adaptation du moteur.....

Vous interprétez comme vous voulez!! On peut aussi dire :
Peut importe le carburant y'a une différence entre un moteur avec et sans turbo : la performance mais aussi le prix!!
Sur ce, je ne défends pas PcSoft mais dans mon cas : on ne s'est pas posé de question et on a pris l'accès natif. Du peu que je me souvienne de mes tests avec odbc, la différence était flagrante!

[step37]

Salut à toi,

Ce n'est pas pour polémiquer, mais dans le cas où il faudrait en effet avoir l'accès natif pour accèder à toutes les fonctionnalités de SQLServer, il me semble en effet "normal" de payer.

Il faut peut-être prendre en compte également que MS a peut-être fait payer PCSoft pour utiliser leurs produits.

C'est comme si PCSoft nous faisait payer l'accès OLEDB ou ODBC.

Le nouvel accès natif Microsoft est gratuit, disponible sur le lien de mon mail d'origine.

Cet accès doit remplacer in fine les autres méthodes.

Qui plus est en achetant les outils PCSoft, j'achète un outils de dev, qui se doit d'être en harmonie avec les normes des produits sur lesquels ils peuvent s'appuyer.

Si j'achetais un outil de dev PCSoft qui ne fonctionne parfaitement qu'avec les base de données PCSoft (qui ne sont pas elle vendues) ou dont l'utilisation avec des produits de marque concurrentes restreint leur utilisation c'est une autre histoire..... Mais ce n'est pas celle annoncé à grand coups de pub.

Bref, cela n'engage que moi, mais payer 747 € + 149 € par mise à jour (sur laquelle je reste d’ailleurs dubitatif car même si la version de Windev évolue la couche d’accès aux données est dépendante de l’évolution de la base de donnée et de la norme accès natif définie par l’éditeur de cette base de donnée) et pour chaque serveur déployé, cela me semble une belle arnaque marketing et une sacré prise d’otage : « Tu paye et tu as la performance ou sinon tu as le gratuit moins performant, ne te permettant pas d’exploiter toutes les capacité de ta BDD»

Cela me choque, cela ne fait pas partie de mon approche d’une relation commerciale, ce type de comportement me semble désuet, à des années lumière des réalités actuelles.

[step37]

Vous interprétez comme vous voulez!! On peut aussi dire :
Peut importe le carburant y'a une différence entre un moteur avec et sans turbo : la performance mais aussi le prix!!
Sur ce, je ne défends pas PcSoft mais dans mon cas : on ne s'est pas posé de question et on a pris l'accès natif. Du peu que je me souvienne de mes tests avec odbc, la différence était flagrante!

Je ne dit pas que techniquement l'accès natif ne se justifie pas, je dit qu'il est gonflé de faire payer une technologie mise à disposition gratuitement par microsoft.

[Emmanuel Lecoester]

Pour avoir travailler longtemps sur les accès natifs (mais de l'autre coté) la démarche de Pc-Soft sur le sujet est simple :

• WinDev => HF,
• Pour les autres bases WinDev est 100% compatible ODBC - OLE-DB
• PC-Soft fournit des accès natifs pour les grandes bases du marché, certains gratuits (MySql...) d'autres payants (Oracle, MSSQL...)

Rien n'oblige techniquement PC-Soft à développer un accès pour toutes les bases du marché. Si tu souhaites accéder à n'importe quelle base de données tu as l'ODBC ou l'OLE-DB dont WD est compatible à 100%.

Maintenant commercialement et si l'utilisateur souhaite une performance accrue pour son accès à ses données (utilisation de la couche bas niveau) PC-Soft fourni un accès natif payant.

Où est le mal ? C'est leur schéma commercial, leur politique commerciale, donc personnellement osef ici

Maintenant pour en revenir au problème initial je réitère : c'est anormal d'ouvrir un curseur (au sens SGBD) au niveau de la base qui reste ouvert après un close. Il faut donc ouvrir un incident coté PC-Soft avec ton cas qui marche dans tous les cas.

Qui paie le temps de développement et de mise au normes pc-soft de la dll encapsulant les accès (même gratuits) à la base ?

[step37]

Emmanuel, il n'y a pas de polèmique simplement une vision très différentes de ce que doit apporter un éditeur en terme de valeur ajouté !

d'autres payants (Oracle, MSSQL...)

Non pas l'accès natif Microsoft, il est gratuit.

Si tu souhaites accéder à n'importe quelle base de données tu as l'ODBC ou l'OLE-DB dont WD est compatible à 100%.

Justement c'est bien là le doute. D'ailleurs mon service dev me semble avoir repéré une autre coquille qui fera l'objet d'une post à venir.

Où est le mal ? C'est leur schéma commercial, leur politique commerciale, donc personnellement osef ici

Qui paie le temps de développement et de mise au normes pc-soft de la dll encapsulant les accès (même gratuits) à la base ?

Et bien se sont les acquéreur de Windev, Webdev !!!
Car nous n'achetons pas une base de donnée mais un outil de développement.

La valeur ajoutée d'un éditeur se paye lorsque celui-ci développe des fonctionnalités complémentaires sur ces propres produits, pas lorsqu'il ne fait qu'être en phase avec les produits avec lesquels il se connecte et pour lesquels il communique allègrement, cela leur apporte aussi au passage une forme une notoriété et une "validation Technique" :"nous fonctionnons parfaitement avec MS SQL, nous gérons parfaitement les service Web, etc, etc..."

Et puis le choix de l'accès natif n'est pas un simple choix de performance, des fonctions apparues sur SQL 2005 / 2008 ne sont pas accèssible via OLEDB / ODBC.

Lorsque ces technos (oledb/ODBC) ne seront plus supportées et que seul les accès natifs resteront, PCSoft ne se connectera plus nativement qu'à son propre SGBD.

Maintenant je préfèrerait que Hyperfile soit vendu à part des autre produits et que nous ayons le choix entre acheter Hyperfile ou l'accès natif d'un produit concurrent.

Malgrès tout le bien (ou le mal pour certains) que l'on pense d'Hyperfile, beaucoup de compte client ne veulent pas voir rentrer cette 'chose' chez eux. Je ne porte pas de jugement en la matière , simple retour terrain dans la réalité quotidienne.

Maintenant pour en revenir au problème initial je réitère : c'est anormal d'ouvrir un curseur (au sens SGBD) au niveau de la base qui reste ouvert après un close. Il faut donc ouvrir un incident coté PC-Soft avec ton cas qui marche dans tous les cas.

Suis parfaitement d'accord avec toi.

Et bien l'incident est ouvert depuis plus d'un mois.......... et rien à l'horizon.

A demain, et bonne soirée

[Emmanuel Lecoester]

Emmanuel, il n'y a pas de polèmique simplement une vision très différentes de ce que doit apporter un éditeur en terme de valeur ajouté !

Non pas l'accès natif Microsoft, il est gratuit.

J'ai édité mon post, je parlais bien de la mise à disposition de l'AN par PC-Soft

Que dit le service technique sur le bug annoncé ? et le service commercial ? Tu as posé ta question sur leur forum ?

[step37]

Que dit le service technique sur le bug annoncé ? et le service commercial ? Tu as posé ta question sur leur forum ?

Et bien la réponse du service Technique est la suivant ;

"J’ai transmis vos nouveaux éléments à notre équipe de développement. Dans l’immédiat, je vous conseille de créer une nouvelle connexion et d’utiliser cette connexion uniquement pour la commande HExporteXML.

L'équipe du Support Technique Gratuit reste à votre disposition."

Et cela depuis le 14/12/09.

Je vais contacter le service commercial et verais si cela fait avancer les choses.

A bientôt,