Hello,
We been using the SQL version of FedEx for about 2 weeks. Today, we have noticed a pretty substantial issue. Whenever we write back back from ShipRush, we are doing so by inserting a fairly comprehensive set of fields into a new record in an SQL Table. Our SQL statement looks like this:
We have discovered that because of the way that ShipRush does exports - first "printing" the ShipRush variables to literal strings and then executing the SQL statement with that literal text embedded - that a quote or apostrophe in a field such as %ToName% will cause the export to fail throwing an invalid syntax error. Today's example was from a shipment to a person with the last name O'Neal.
The major problem with this is it cannot be effectively handled in the SQL statement. If we were dealing with an actual SQL variable there are plenty of ways in could be handled with functions or procedures, but because this data has already been downgraded into a literal text string by the time the SQL statement executes, none of those options are available without first encapsulating the text within two single quotes. Encapsulating the text within two single quotes will not work however, because SQL will read the literal quote within the text string as the closing quote.
For example, the portion of the statement above:
becomes:
at the time the time the SQL statement executes. The extra quote will cause it to throw a syntax error.
If you try to wrap '%ToName%' in a SQL function to handle the quotes like master.dbo.EscapeQuotes('%ToName%') it will still fail because you are effectively running master.dbo.EscapeQuotes('Tom O'Neal') wherein the function will have a syntax error because it sees too many quotes.
You can try this yourself. Just try to execute SELECT REPLACE('Tom O'Neal',CHAR(39), CHAR(39) + CHAR(39)) in any version of MS SQL and it will fail because there are too many quotes and there is no way to run a function or stored procedure against a literal string without encapsulating it in quotes.
There are escape characters that can be used when a programmer is typing a literal string into a SQL statement, however this is also not viable because it is ShipRush that is injecting its variables as literals into the SQL statement and such escape characters would have to directly precede the character being escaped.
With my 13 years of experience as a SQL developer I can say with a very high degree of certainty that the is no way that this issue can be resolved through changes to the SQL statement that does the write back. The only way this can be resolved is through Z-Firm making changes to ShipRush.
We been using the SQL version of FedEx for about 2 weeks. Today, we have noticed a pretty substantial issue. Whenever we write back back from ShipRush, we are doing so by inserting a fairly comprehensive set of fields into a new record in an SQL Table. Our SQL statement looks like this:
Code:
INSERT INTO dbo.TempTrackingExport(InvoiceNumber, UPSDate, TimeStamp, QBFileAsName, ServiceType, PubBoxCost, PubTotalShipmentCost, DiscBoxCost, DiscTotalShipmentCost, TrackingNumber, VoidIndicator, Weight, Customer, Street1, City, State, ZipCode, Country, Division, Ref2, BillingOption, ESMAccount, EnteredAs, ShipRush)
SELECT %RecordID% AS InvoiceNumber, CONVERT(varchar, Shipping.dbo.FedExExpressCurrentShippingDate(), 101) AS UPSDate, GETDATE() AS TimeStamp, '%ToName%' AS QBFileAsName, '%ShippingService%' AS ServiceType, %ShippingCharges% AS PubBoxCost, %ShippingCharges% AS PubTotalShipmentCost, %ShippingCharges% AS DiscBoxCost, %ShippingCharges% AS DiscTotalShipmentCost, '%TrackingNumber%' AS TrackingNumber, 'N' AS VoidIndicator, %ShippingWeight% AS Weight, '%ToName%' AS Customer, '%ToStreet1%' AS Street1, '%ToCity%' AS City, '%ToStateOrProvince%' AS State, '%ToZIP%' AS ZipCode, '%ToCountry%' AS Country, Shipping.dbo.FedExOneRateOrderSource() AS Division, '%RecordID%' AS Ref2, 'Bill Sender' AS BillingOption, Shipping.dbo.FedExOneRateSourceAccounts() AS ESMAccount, %RecordID% AS EnteredAs, 1 AS ShipRushThe major problem with this is it cannot be effectively handled in the SQL statement. If we were dealing with an actual SQL variable there are plenty of ways in could be handled with functions or procedures, but because this data has already been downgraded into a literal text string by the time the SQL statement executes, none of those options are available without first encapsulating the text within two single quotes. Encapsulating the text within two single quotes will not work however, because SQL will read the literal quote within the text string as the closing quote.
For example, the portion of the statement above:
Code:
CONVERT(varchar, Shipping.dbo.FedExExpressCurrentShippingDate(), 101) AS UPSDate, GETDATE() AS TimeStamp, '%ToName%' AS QBFileAsName, '%ShippingService%' AS ServiceType,Code:
CONVERT(varchar, Shipping.dbo.FedExExpressCurrentShippingDate(), 101) AS UPSDate, GETDATE() AS TimeStamp, 'Tom O'Neal' AS QBFileAsName, 'FedEx 2Day?' AS ServiceType,If you try to wrap '%ToName%' in a SQL function to handle the quotes like master.dbo.EscapeQuotes('%ToName%') it will still fail because you are effectively running master.dbo.EscapeQuotes('Tom O'Neal') wherein the function will have a syntax error because it sees too many quotes.
You can try this yourself. Just try to execute SELECT REPLACE('Tom O'Neal',CHAR(39), CHAR(39) + CHAR(39)) in any version of MS SQL and it will fail because there are too many quotes and there is no way to run a function or stored procedure against a literal string without encapsulating it in quotes.
There are escape characters that can be used when a programmer is typing a literal string into a SQL statement, however this is also not viable because it is ShipRush that is injecting its variables as literals into the SQL statement and such escape characters would have to directly precede the character being escaped.
With my 13 years of experience as a SQL developer I can say with a very high degree of certainty that the is no way that this issue can be resolved through changes to the SQL statement that does the write back. The only way this can be resolved is through Z-Firm making changes to ShipRush.