Thank you for visiting our Partner Zone. This area is an exclusive space for MYOB Partners. Find out how to Partner with MYOB.
January
January
I am exporting 3 Files from Accountright live to .TXT Files on my local machine.
Customers (all fields - Tab Delimited) - No Problems
Items (all fields - Tab Delimited) - Problem with spurious Hex 0A characters inserted into a line exported - unpredictable Items involved but the Hex 0A seems to be be more frequent where there is a long Description for the Item.
ItemSalesData(all fields - Tab Delimited) - Problem with spurious Hex 0A characters inserted into a line exported - unpredictable ItemSalesData lines involved but the Hex 0A seems to be be more frequent where there is a long Description for the Item.
Problem exists whether the export is Comma Delimitted or Tab Delimited
I have been able to create a work around to the problem, but I am sure MYOB needs to know about bugs in their system as most users who use the Import/Export options are not necessarily computer programmers
January
January
Hi @ITM , hex 0A is a line feed character, so most likely the item description contains a line feed either intentionally or because someone has pressed Enter after typing it, which does affect txt files I agree, but is data driven, not really a bug.
Regards, Mike (mike@datawise.co.nz)
DataWise Limited (www.datawise.co.nz), developers of:
DataWise ProActive - Custom Reporting from MYOB programs
(MYOB Business, including AccountRight Live, AccountRight v19.x and exo Payroll)
Bulk download of attachments (more details...)
January
January
The problem with HEX 0A in the data is that the data cannot be easily imported into a database as the continuation of the description is now at the beginning of the next text line (Which normally, in the case of ItemSales data, is the Company Name Field)
The importing of such raw data therefore becomes useless unless it is "cleaned up"
So that's what I have done - Read the export line by line and remove the lonely HEX 0A characters
You may well be correct that the operator may have pressed an enter while keying the description but I do not have HEX 0D0A other than at the end of the line, which I expected
SOLUTION
The trick is to read the file - Scan the file looking for HEX 0A0D together - replace the HEX 0A0D with HEX FFFF - Rescan the file looking for HEX 0A - Replace with a space - Rescan the file looking for HEX FFFF - replace the HEX FFFF with HEX 0A0D
Works for me - perfectly
A little challenge but all good
Thank you so much for your interest !
January
January
Hi, @ITM
Thanks for your post.
Thanks for expressing your concern. Rest assured that we take your feedback seriously to improve our services.
Thank you, @Mike_James for replying to this post. We truly appreciate it.
Best regards,
Doreen
Online Help| Forum Search| my.MYOB| Download Page
Did my answer help?
Accept it as a Solution
Leave a to tell others
January
January
I have performed further checking into the HEX 0A character appearing by itself in the line.
I have found that by deliberately pressing the Enter Key in the middle of the ITEM Description, this has no effect on the description when it is Exported. ie, Pressing the Enter Key does not introduce a HEX 0A to the data.
This therefore confirms my original belief that there is actually an error when the Export Utility is used.
As I said, I have had to write special software to "Clean" the data exported from the Export Utility, and this seems to work.
I am just concerned that normal MYOB users who do not have programming experience will find that the Export Data utility will cause them errors if they attempt to used the exported data in Excel or perhaps a database like Access.
Thank you for everyone's interest.
January
January
I've seen a lot of dirty data in my time an I suspect that the Hex 0A characters in item descriptions were not created when exporting the data, but when the data was IMPORTED from a different system some time in the past.
41
|
3286
|
|||
33
|
1537
|
|||
32
|
887
|
|||
12
|
874
|
|||
8
|
897
|