Our clients want so their Customers have colons ":" in the company name (e.g. Rob:Barnett:Company'). Syncing such customer to QBO v3 cause the error
com.intuit.ipp.exception.FMSException: ERROR CODE:2040, ERROR MESSAGE:Invalid String. The String may contain unsupported or illegal chars, ERROR DETAIL:Element contains invalid characters. Rob:Barnett:Company
That is probably because QBO v3 entities are being split with colons when the hierarchy is used (Parent:Customer:Job). So, is there a way for our guys to have colons in the company name, or this is impossible?
BTW, QBO web-face say that a field is invalid when trying to do so.
QuickBooks uses colons as a special character to delineate parent/child heirarchies.
Thus, you can not have colons in customer names.
Related
I need to use/store a delimiter separated value string (not csv) of email addresses. I need to choose a delimiter that is safe.
E.g. bar#foo.com,baz#foo.com, - comma in this e.g. is unsafe as it's valid within an email address.
It seems that almost anything is allowed in an email address, especially now with internationalized email addresses.
What is a safe delimiter to use without jumping through hoops because of corner cases? I can't find a character in the RFC which which is expressly invalid (but there are lots of email related related RFCs, so I'm not sure which to consult).
Where/how will you be storing the string and what will the delimiter be used for?
You could use a non-visible ascii character such as the CR (Ascii 13) or Tab (Ascii 9).
I originally used \ because that is an escape character, however it is allowed if escaped. #MatWalker's answer recommends stuff like CR or LF etc, but those are allowed too, if they are escaped.
Escaping and replacing and unescaping got a bit complicated. So right now I'm using control character STX (i.e. "Start of Text", decimal 2).
Although the RFC doesn't mention (from what I've seen) whether control charactes are valid/invalid, there doesn't seem to be anything that makes it a bad choice. It does say that control chars are "discouraged", but not prohibited for header fields.
I am trying to create multiple html files that are associated with an email address. But since the "#" cannot be used in filenames, and in order to avoid confusion, I am trying to replace it with a character that won't normally exist in an email address.
Anything comes in mind?
Thanks!
Comma and semi-colon is not allowed in email address but in filenames on most file systems.
I believe '~' is used for this purpose.
According to the link here almost all ASCII characters are allow in email addresses so long as the special characters aren't at the beginning or the end.
What characters are allowed in an email address?
Any of , (comma) ; (semi-colon) <> (angle brackets) [] (square brackets) or " (double quote) should work for most cases.
Since these characters are allowed in quoted strings, you could replace the "#" with a sequence that would be invalid such as three double quotes in a row.
According to the RFC
within a quoted string, any ASCII graphic or space is permitted without blackslash-quoting except double-quote and the backslash itself.
You could have an email abc."~~~".def#rst.xyz. But you could not have abc.""".def#rst.xyz; it would have to be abc.""".def#rst.xyz. So you could safely use """ as a substitute for # in the filename.
However, the RFC also says
While the above definition for Local-part is relatively permissive,
for maximum interoperability, a host that expects to receive mail
SHOULD avoid defining mailboxes where the Local-part requires (or
uses) the Quoted-string form or where the Local-part is case-
sensitive.
With SHOULD meaning "...that
there may exist valid reasons in particular circumstances when the
particular behavior is acceptable or even useful, but the full
implications should be understood and the case carefully weighed
before implementing..." RFC2119
So, although """ will work, are the chances you will see an email with quotes worth the trouble of designing for it? If not, then use one of the single characters.
Googling I've found this DB2 Function declaration:
CREATE FUNCTION QGPL.SPLIT (
#Data VARCHAR(32000),
#Delimiter VARCHAR(5)
)
Whats means # symbol before the Variable Name?
Regards,
Pedro
The # character is simply the first character of the SQL identifier [variable name] naming the parameter defined for the arguments of the User Defined Function (UDF); slightly reformatted [because at first glance I thought that revision might make the at-symbols appear more conspicuously to be part of the name, though now I think probably not]:
CREATE FUNCTION QGPL.SPLIT
( #Data VARCHAR(32000)
, #Delimiter VARCHAR(5)
) returns ...
Put simply, the use of the # character in an identifier is highly discouraged; the use of such variant characters, although supported in standard object naming, they can cause great pains and difficulties, including some that are insurmountable:
http://www.ibm.com/support/knowledgecenter/api/content/ssw_ibm_i_71/db2/rbafzch2iden.htm
Identifiers
An identifier is a token used to form a name. An identifier in an SQL statement is an SQL identifier, a system identifier, or a host identifier.
Note: $, #, #, and all other variant characters should not be used in identifiers because the code points used to represent them vary depending on the CCSID of the string in which they are contained. If they are used, unpredictable results may occur. [...]
[Edit-addendum 17May2015]
http://www.ibm.com/support/knowledgecenter/api/content/nl/en-us/SSEPGG_10.5.0/com.ibm.db2.luw.admin.dbobj.doc/doc/c0004625.html
Naming rules in a multiple national language environment
The basic character set that can be used in database names consists of the single-byte uppercase and lowercase Latin letters (A…Z, a…z), the Arabic numerals (0…9) and the underscore character (_).
This list is augmented with three special characters (#, #, and $) to provide compatibility with host database products. Use special characters #, #, and $ with care in a multiple national language environment because they are not included in the multiple national language host (EBCDIC) invariant character set. Characters from the extended character set can also be used, depending on the code page that is being used. If you are using the database in a multiple code page environment, you must ensure that all code pages support any elements from the extended character set you plan to use.
[...]
[/Edit-addendum 17May2015]
I'm using the .NET SDK to import customers and transactions from another system that accepts UTF-8 encoding in their data, and am having a lot of trouble with special characters. Is there a comprehensive list of (a) what characters need to be escaped (like apostrophe), and (b) what characters are simply not allowed in QBO (like colon)? All I can find in the online doc is "use backslash to escape special characters like apostrophe". OK, what about ampersand, em dash, en dash, grave accent, acute accent... you get the idea.
This problem affects both queries and inserts which causes all kinds of problems. For example, if we query a customer by name, and the query fails (maybe due to an invalid character), we try to insert the customer in QBO, which of course also fails, either due to the customer existing or invalid characters. True, we can usually figure out if the query failed due to a bad character vs the record not existing, but we need a design-time solution. Any suggestions?
If you use Query endpoint, then please URL encode the query parameters.
For ex -
For the following query
select * from Customer where DisplayName='Aülleünte'
URL request would be
https://quickbooks.api.intuit.com/v3/company/<relamId>/query?query=select+*+from+Customer+where+DisplayName%3D%27A%C3%BClle%C3%BCnte%27
PN - Some QBO textfields(for ex - 'Description/Note' of Customer window) allow to enter control characters which gets returned as part of query response. As some of those characters are not supported in XML, object deserialization fails/shows warning.
You should either remove those characters from UI or you need to use some lib/regex in the client side code to remove those characters programmatically. Ideally it should be handled in the server side.
QBO Global UI supports UTF-8 encoding for sure. But It seems, QBO US UI behaves differently while dealing with special characters.
For ex - In QBO US UI, if you enter '你好嗎' then after saving, it gets converted to '}Î'.
Edit
Here is a list of accepted characters:
•Alpha-numeric (A-Z, a-z, 0-9)
•Comma (,)
•Dot or period (.)
•Question mark (?)
•At symbol (#)
•Ampersand (&)
•Exclamation point (!)
•Number/pound sign (#)
•Single quote (')
•Tilde (~)
•Asterisk (*)
•Space ( )
•Underscore (_)
•Minus sign/hyphen (-)
•Semi-colon (;)
•Plus sign (+)
On page 34 of 70-461 Querying Microsoft SQL Server 2012 it says that an indentifier is regular if:
The rules say that the first character must be a letter in the range
A through Z (lower or uppercase), underscore (_), at sign (#), or
number sign (#). Subsequent characters can include letters, decimal
numbers, at sign, dollar sign ($), number sign, or underscore.
However on pg 271 it says:
Even though you can embed special characters such as #, #, and $ in
an identifier for a schema, table, or column name, that action makes
the identifier delimited, no longer regular.
So to clarify would having special characters like the '$' an identifier regular or not
Having $ after the first character is part of the specification that defines a regular identifier and will not require the use of a delimiter.
I found the definition in SQL Server 2008 R2 Identifiers to be clearer than the one from page 34. It is essentially the same as the one on page 271, but with more detail.
Either you have misquoted pg 271 of the book, or your version is different than mine and has an error:
If you embed special characters other than #, #, and $ in an
identifier for a schema, table, or column, name, that action makes the
identifier delimited, no longer regular.
Here is a regular expression that will match a string that complies with the definition:
^[\p{letter}_##][\p{Letter}\p{Number}_##$]*$
Regex for flavors without unicode support:
^[a-zA-Z_##][a-zA-Z\d_##$]*$