Subscribe via RSS
Toggle Submenu
  1. Categories
  2. Recent
  3. Tags
View Replies (6)

Resolved ON HOLD: FileWrite now creating a space between each character!

  1. Issue
0
Votes
Undo
  1. Olan Knight
    Olan Knight
  2. PowerBuilder
  3. Tuesday, 22 May 2018 19:13 PM UTC

PB v12.1, build 7055
Windows 7, 64 bit platform
Oracle 12C


UPDATE - 23-MAY-2018

Kim, Chris, and John - thank you for your suggestion and your time!

I've learned that the issue is intermittent and it appears that it has something to do with the way the data is being handled; we're moving the data servers and the data from one location to another. I've been told to hold off until the move is complete, and we MAY pick this back up if the issue recurs.

Thank you all again!

--------------------------------------------------------------------------------------------------------------------------------------

UPDATE - 22-MAY-2018

I've researched this on the web with no luck yet.

I have also tried duplicating the problem by specifically adding the ENCODING options to the FileOpen command, one at a time.
·     EncodingANSI! (default)·  EncodingUTF8!·  EncodingUTF16LE!·  EncodingUTF16BE!

The output was identical in each case. As expected, the two UTF16 output files used double the disc space of the UTF8 and the ANSI options. These four extract files are attached.

--------------------------------------------------------------------------------------------------------------------------------------
The code we've been using for years to write a text file is suddenly generating a space between each output character.
We are getting "S E C A B  1 5 "  instead of "SECAB 15".

The command is:  ll_Write = FileWriteEx( ii_FileWrite, is_Mech )

I suspect that the platform itself is setting the ASCII character set, and is using ASCII 16 instead of ASCII 8.
However, I've no idea if this is the issue or not.
If it is the issue, how do I get my standard text output back?


Thank You,
Olan

  1. Output
  2. File
How can i do a command line build in powerbuilder?
.NET Web Service Target and HttpClient
Responses (6)
Salvador Rodriguez
Salvador Rodriguez Accepted Answer Pending Moderation
  1. Friday, 18 August 2023 20:11 PM UTC
  2. PowerBuilder
  3. # 1

Hi,

We had the same problem after migrating to PB17, PB19, PB21 and recently PB22 in two of our applications that use PFC.
I don't know since when it happened, but we noticed that if you use Notepad++ to open the file, it opens correctly while using Notepad opens it with spaces between each character.

I don't know if there is another solution... but What worked for me is to open it in textmode and convert the blob variable to string before calling FileWriteEx. 

li_FileNo = FileOpen(as_FileName, TextMode!, Write!, LockReadWrite!, lwm_Mode)
...
If FileWriteEx(li_FileNo, string( lblb_Data ) ) = -1 Then
     Return -1
End if

Note: If the file was opened in text mode, FileWrite returns -1, so it can't be use, only the new FileWriteEx works. 

Regards... Salvador.

Comment
There are no comments made yet.
Olan Knight
Olan Knight Accepted Answer Pending Moderation
  1. Thursday, 2 August 2018 22:41 PM UTC
  2. PowerBuilder
  3. # 2

Well, the data servers have been moved, and this issue has not recurred.

At this time we're calling it and "anomaly" and letting it go.

 

Thanks to all for your thoughts and ideas!

Olan

Comment
There are no comments made yet.
Govinda Lopez @Appeon
Govinda Lopez @Appeon Accepted Answer Pending Moderation
  1. Wednesday, 23 May 2018 15:53 PM UTC
  2. PowerBuilder
  3. # 3

Hi Olan,

 

Have you tried using the TextMode! Instead of the LineMode!? Maybe a combination between those and your Enconding options.

 

 

Regards,

Comment
There are no comments made yet.
John Fauss
John Fauss Accepted Answer Pending Moderation
  1. Tuesday, 22 May 2018 21:36 PM UTC
  2. PowerBuilder
  3. # 4

I agree with Chris that this is likely a Unicode vs ANSI issue. Maybe a PB (Unicode) string converted to a blob and written to disk using StreamMode? Does the FileOpen for this file specify character encoding? EncodingANSI! is the default if not explicitly specified.

Comment
There are no comments made yet.
Chris Pollach @Appeon
Chris Pollach @Appeon Accepted Answer Pending Moderation
  1. Tuesday, 22 May 2018 19:36 PM UTC
  2. PowerBuilder
  3. # 5

Hi Olan;

   Sounds like an ANSI vs UNICODE issue. Check how that string gets built, where the text comes from and any PowerScript commands that might have the Ansi! vs Unicode! options set somewhere that manipulate this string

Regards ... Chris

Comment
Olan Knight
  1. Olan Knight
  2. Tuesday, 22 May 2018 22:02 PM UTC
My FileOpen command is:

        ii_FileWrite = FileOpen( ls_File, LineMode!, Write!, LockReadWrite!, Replace!)



I tried adding the specific values for ENCODING - all four of them - and could not replicate the problem.

·    EncodingANSI! (default)·    EncodingUTF8!·    EncodingUTF16LE!·    EncodingUTF16BE!



All four output files had the same data. As expected, the two UTF16 files used double the space of the ANSI and UTF8 options even though the output was identical visually.

  1. Helpful
Chris Pollach @Appeon
  1. Chris Pollach @Appeon
  2. Wednesday, 23 May 2018 13:22 PM UTC
Hi Olan;



  You might have to follow the file datum processing via the debugger to see where the weird spacing gets introduced.



Regards ... Chris

  1. Helpful
There are no comments made yet.
Kim Berghall
Kim Berghall Accepted Answer Pending Moderation
  1. Tuesday, 22 May 2018 19:26 PM UTC
  2. PowerBuilder
  3. # 6

It probably has to do with the string hvariable is beeing populated.. Also, a related issue, the FileOpen filemode has also changed, it is not really clear to me but you have to use either LineMode! or TextMode! (we are using TextMode!).

Comment
There are no comments made yet.
  • Page :
  • 1


There are no replies made for this question yet.
However, you are not allowed to reply to this question.
We use cookies which are necessary for the proper functioning of our websites. We also use cookies to analyze our traffic, improve your experience and provide social media features. If you continue to use this site, you consent to our use of cookies.