ERROR [S0000] [Acomba ODBC Driver]

[Jeremie]

Bonjour,

J'ai cette erreur quand je fait rouler ma query pour inséré une commande.

ERROR [S0000] [Acomba ODBC Driver]Invalid operand for operator: < assignment >

Voici la query (Formater pour VB.Net):

Code:


" Insert Into Invoicing ( InStatus,InUniqueUser, InTimeModified, " _
                    & "  InInvoiceType, Indate, InCustomerSupplierCP, InCustomerSupplierNumber, " _
                    & " InName, InCareOf, InAddress, InCity,InPostalCode, InISOCountryCode,  " _
                    & " InPhoneDescription1,InPhoneDescription2, InPhoneNumber1,InPhoneNumber2,  " _
                    & " InShipName, InShipCareOf,InShipAddress, InShipCity, InShippostalCode, " _
                    & " InShipISOCountryCode, InShipPhoneDescription1,InShipPhoneDescription2, " _
                    & " InShipPhoneNumber1,InShipPhoneNumber2,InInvoiceNumber, InAssociatedBid,  " _
                    & " InSalesRepCP, InSalesRepNumber, InTermType, InTermDescription,    " _
                    & " InTaxGroupCP,InTaxGroupNumber,  InTransactionTotal, InTransactionSubTotal)  " _
                    & " VALUES(0," & iThomasId & ",'" & Date.Today.ToString() & "',2,'" _
                    & Date.Today.ToString() & "'," & iCustomerCU & ",'" & noClient & "','" & sName _
                    & "','" & sCareof & "','" & sAdress & "','" & sCity & "','" _
                    & sCp & "','" & sIso & "','Téléphone','Fax','" & sTel _
                    & "','" & sFax & "','" & sShipName & "',' " & sSCare _
                    & "','" & sShipAddress & "','" & sShipCity & "','" _
                    & sShipCp & "','" & sShipIso & "','Téléphone','Fax','" _
                    & sShiptel & "','" & sShipFax & "'," & icom _
                    & "," & iQuotationId & "," & iRepId & ",'" & sRepNum _
                    & "'," & iTerm & ",'" & sTermDesc & "'," & iTaxeId _
                    & ",''," & dTotal & "," & dSubTotal & ") "

Dans Accès, ça me dit qu'il y a une erreur de conversion de type, sauf que j'ai beau relire et relire la requête et le descriptif de la table Invoicing ... je ne vois pas se qui cloche.

Merci.

Puis, le InUnique est-ce qu'il va s'incrémenté tous seul ou voudrait que je le rajoute ?

[PlanteG]

Il y a une date dans la requête, et la valeur assignée est Date.Today.ToString(), ce qui est invalide pour une date. Voir cet autre fil de discussion https://aideacomba.forum-canada.com/odbc-f18/syntaxe-sql-t749.htm pour la façon de spécifier une date.

[Jeremie]

Heu !

Les # fonctionnes pas plus, mais je vais tester entre {} ...

Après essai, non j'ai toujours le même message d'erreur.

"ERROR [42000] [Acomba ODBC Driver]Expected lexical element not found: "

[PlanteG]

D'après une petite recherche sur Internet, le message d'erreur "ERROR [42000] [Acomba ODBC Driver]Expected lexical element not found: " devrait indiquer à quel endroit dans la requête le problème est soulevé.

Une suggestion: simplifier la requête afin de déterminer quel champ la fait dérailler.

À cette adresse http://msdn.microsoft.com/en-us/library/ms190234 , on décrit le format de ODBC Datetime Format.

[Jeremie]

Si cela devrait me dire où c'est, mais ce n'est pas le cas.

Pas l'air d'être les dates ... si je dois tester chaque champs un à un ...

Pffft ! vive SQLServer tiens.

Bon, je vais tester autre chose.

Edit :

Après avoir retirer les dates de la requêtes, je revient au point de départ.
Accees me donne encore une erreur de format et l'erreur Invalid Operant for operator ; < invalid assignement >

Edit 2 :

Peux pas essayé chaque champ un à un ... table Invoicing ouvert en lecture seul ...
Je viens d'écrire au support technique.

perte de temps ...

[hench]

hello,

champs de date entre #, et sans apostrophes peut-être

J'aimerais tester mais je n'ai pas de setup sql server ! :(

Lors de l'affichage d'une date lors d'un SELECT, quel est son format d'affichage ??

Bon succès !!

[Jeremie]

C'est pas les dates, je l'ai es viré de la query.

Et je peux pas tester un à un savoir se que l'odbc aime pas, ça me dit que c'est en lecture seule.

En SqlServer, il y a un format date et on peux en vb déclarer des variables SQL.

Se qui fait que tu as pas gérer les ' dans une String ou les autres signes refusé par le SQL.
Mais bon, Acces étant inférieur et l'odbc est au même niveau dans le .Net ben ... en attendant, je finalise mes autres points.

Doit être une connerie comme d'habitude, mais la quel ?

EDIT :

Reçu une réponse des gens d'Acomba.

Utilisait pas les bonne table ... :msn!:

il faut utiliser les tables TransactionHeader et TransactionDetail du pilote ODBC. De plus, il faut utiliser les commandes BEGIN_TRANSACTION_IN, END_TRANSACTION_IN, CANCEL_TRANSACTION_IN et CALCULATE_TAXES. Pour vous aidez à comprendre la façon dont vous pouvez utiliser les tables et commandes identifiées ci-dessus, vous pouvez consulter le fichier qui a été joint au courriel et qui contient un exemple. Il est à noter que le fichier d'aide du pilote ODBC pour Acomba contient la définition complète des tables TransactionHeader et TransactionDetail.

Si même leurs table sont pas compréhensible .... :compu1:

[PlanteG]

J'ai travaillé avec SAP Business ONE, l'ERP d'entrée de gamme de SAP. Avec SAP aussi, il y a la notion de Header et Detail. Et si vous croyez que les tables d'Acomba sont complexes, alors il ne faut pas s'aventurer dans Business One . Des tonnes et des tonnes de colonnes, avec des noms qui ne disent rien souvent.

[Jeremie]

J'ai l'habitude des header, detail.

Ce que je trouve fou, c'est que c'est tellement pas optimisé, devait pas connaitre le 3FN en 95...

[PlanteG]

devait pas connaitre le 3FN en 95

La base de données d'Acomba n'est pas relationnelle, elle est de type ISAM. Il ne faut pas oublier que cette bd maison a été créée pour Fortune 1000, l'ancêtre d'Acomba sous DOS. Quand Acomba est arrivé, on a décidé d'utiliser le même système. Sans refaire toute l'histoire, à l'époque cela était une décision défendable. Alors les formes de normalisation en ISAM...

Mais aujourd'hui, compte tenu du nombre de module qui se greffent à Acomba et de la taille des données (nombre d'enregistrements), la bd ISAM affiche des rides. C'est pourquoi on va passer à MS SQL Express/Postgre.

Et ce n'est pas parce que l'on a un SGBD relationnel que c'est nécessairement meilleur. Je reviens à SAB Business One: aucune relation de définie entre les tables, et donc pas de enforce integrity. Tout est fait par programmation. Le résultat ? Des factures faites à un client qui n'existe plus par exemple. Et des clefs sur des noms de client par exemple plutôt que sur des clefs numériques comme des autonumber. Croyez moi, une bd Business One peut devenir un cauchemard .

[Jeremie]

J'en doute pas une seconde.

Même avec une BD relationnelle, on peut se retrouver avec des bizarreries.

On a mis la hache dans certaine relation, les modules n'étant pas encore coder ou parce que certaines tables sont pas dans la BD.

Ou avoir des trucs doublons, parce que Cristal reports est allergique au source de données Mixte.

Mais bon c'est ça la programmation ... et c'est se qui fait que c'est pas trop routinier.

[PlanteG]

Ou avoir des trucs doublons, parce que Cristal reports est allergique au source de données Mixte.

Crystal Report... Le produit qui à ma connaissance est le plus utilisé dans son domaine. La dernière fois que j'ai visité le Web sur le sujet, plusieurs utilisateurs garochaient des pots en masse à ce produit, entre autre su sujet des sources de données. Je ne l'ai jamais utilisé, honnêtement les propos ne m'invitaient pas à l'utiliser. Par contre des fois ces propos n'ont aucune valeur. Difficile de se faire une tête avec ce que l'on lit sur Internet .

[Contenu sponsorisé]