Main   Products   Offshore Outsourcing   Customers   Partners   ContactUs  
JDBC Databases
  HXTT Access v7.1
  HXTT Cobol v5.0
  HXTT DBF v7.1
  Buy Now
  HXTT Excel v6.1
  HXTT Json v1.0
  HXTT Paradox v7.1
  HXTT PDF v2.0
  HXTT Text(CSV) v7.1
  HXTT Word v1.1
  HXTT XML v4.0
Offshore Outsourcing
Free Resources
  Firewall Tunneling
  Search Indexing Robot
  Conditional Compilation
  Password Recovery for MS Access
  Password Recovery for Corel Paradox
  Checksum Tool for MD5
  Character Set Converter
  Pyramid - Poker of ZYH
Heng Xing Tian Tai Lab of Xi'an City (abbr, HXTT)

Memo Field Conflict
Omar Cornejo
2006-06-29 12:06:56
I have to withdraw the value of a memo field in my app, and then insert that value in another record. In certain records, the info that i withdraw ir corrupt. It contains the real data of the memo field, and then a \u001a character followed by scrambled info of another recognizable (but no existence justificable) memo fields in the table. How can i obtain correctly the info of all my memo fields?
Re:Memo Field Conflict
HXTT Support
2006-06-29 18:13:28
Yeah. A normal DBT memo data should end with 0x1a 0x1a flag, but it seems that some data is abnormal with only one 0x1a flag. What's the original data source for invalid memo data? You can use indexOf('\u001a') and substring to fix those data.
Re:Re:Memo Field Conflict
Omar Cornejo
2006-06-30 08:15:55
I've already used that solution (indexOf). And works well, but my question was about avoiding this method, maybe changing some property or configuration of the library.

As I told you, i have to "move" the info from a table to another, to later modify that info in the second table. I'm afraid that if the library detects only de "0x1a 0x1a" flag and not the "0x1a" flag, my data would become corrupt, because the data to be written have to be modified by a clipper app.

May I'd be worried about it? or it does not cause any additional troubles?
Re:Re:Re:Memo Field Conflict
HXTT Support
2006-06-30 08:46:25
>I'm afraid that if the library detects only de "0x1a 0x1a" flag and not the "0x1a" flag
Yeah because Only 0x1a 0x1a flag is normal.

If your data is modified by Clipper application at the same time, you should use lockType=CLIPPER to avoid the possible 0x1a.

Search Key   Search by Last 50 Questions


Copyright © 2003-2019 Heng Xing Tian Tai Lab of Xi'an City. | All Rights Reserved. | Privacy | Legal | Sitemap