ADS not executing SQL insert with ANSI characters with later X# version

This forum is meant for questions and discussions about the X# language and tools
Post Reply
ic2
Posts: 1858
Joined: Sun Feb 28, 2016 11:30 pm
Location: Holland

ADS not executing SQL insert with ANSI characters with later X# version

Post by ic2 »

We use a WCF solution which basically fetches MySQL records containing SQL queries, using an X# program which inserts these in the right DBF file residing on a a Pc or server. This has worked without problems and unchanged for years.

A while ago I made some small changes in the logging. On compiling I also had to add CrLf as a global as this wasn't included anymore for some reason in the later Vulcan version. These minor changes where the only ones in 2 years. After that inserting queries which contained ANSI characters as ï or ë failed using:

nStatus := ACE.AdsExecuteSQLDirect( hStmt, cSQLStatement, hPtr)

So nothing has changed in anything remotely to do with the ADS/SQL code. I still include the Vulcan classes and the AdvantageRDD from 2016. When I (only) restore the 2018 .exe (and do not change any of the DLL's) it inserts the "ansi statements" without problems. Only other difference except these minor code changes is that it has been compiled with a later X# version (2.5.2.0) instead of the version of around June 2016.

Final remark is that when I copy the failing INSERT query and insert it in the ADS DataArchitect it inserts without problems in the DBF.

Is there anything which could explain this?

Dick
User avatar
Chris
Posts: 4906
Joined: Thu Oct 08, 2015 7:48 am
Location: Greece

ADS not executing SQL insert with ANSI characters with later X# version

Post by Chris »

Hi Dick,

You said that the old version works, are you testing both the old and the new .exe in the same PC, or in different ones?
Chris Pyrgas

XSharp Development Team
chris(at)xsharp.eu
ic2
Posts: 1858
Joined: Sun Feb 28, 2016 11:30 pm
Location: Holland

ADS not executing SQL insert with ANSI characters with later X# version

Post by ic2 »

Hello Chris,

On the same Pc. As soon as I run the 2018 created X# exe, it executes all the INSERT statements without failure, the new ones and the one with an ANSI character. DLL's are unchanged and a compare from a 2018 backup only reveals the small logging & CrLf definition as changes.

Dick
Jamal
Posts: 315
Joined: Mon Jul 03, 2017 7:02 pm

ADS not executing SQL insert with ANSI characters with later X# version

Post by Jamal »

I worked with Advantage in C# and used X# AXDBFCDX RDD. I had to use SetAnsi(FALSE) for the DBF insert/update to work.

HTH,
Jamal
ic2
Posts: 1858
Joined: Sun Feb 28, 2016 11:30 pm
Location: Holland

ADS not executing SQL insert with ANSI characters with later X# version

Post by ic2 »

Hello Jamal,
SetAnsi is set to false in the program.
Dick
User avatar
Chris
Posts: 4906
Joined: Thu Oct 08, 2015 7:48 am
Location: Greece

ADS not executing SQL insert with ANSI characters with later X# version

Post by Chris »

Hi Dick,

Can you please send me the two exe files, together with all the needed dlls (including the vulcan ones), so I can compare here (with a reflector tool) and see the difference?
Chris Pyrgas

XSharp Development Team
chris(at)xsharp.eu
User avatar
robert
Posts: 4520
Joined: Fri Aug 21, 2015 10:57 am
Location: Netherlands

ADS not executing SQL insert with ANSI characters with later X# version

Post by robert »

Dick,
I think you can completely circumvent this problem by calling this:

nStatus := ACE.AdsExecuteSQLDirectW( hStmt, cSQLStatement, hPtr)

This calls the unicode version of the ExecSQLDirect() function so workstation settings have no influence.

Robert
XSharp Development Team
The Netherlands
robert@xsharp.eu
ic2
Posts: 1858
Joined: Sun Feb 28, 2016 11:30 pm
Location: Holland

ADS not executing SQL insert with ANSI characters with later X# version

Post by ic2 »

Hello Robert,
robert wrote:Dick,
I think you can completely circumvent this problem by calling this:
nStatus := ACE.AdsExecuteSQLDirectW( hStmt, cSQLStatement, hPtr)
quote]

I tried that but got the same result. I've sent the binrelease content + the 2018 (and working) .exe to Chris, hopefully he can quickly see something which explains this.

Dick
Post Reply