|
|
Groups: Member
Posts: 6
|
I'm running the SQL samples on the 64-bit Address Object COM/dlls. After running sp_VerifyAddress, the resulting LIST table has 90 rows where the Results field is empty. 8 rows have AE02 and 7 have AE10.
It is my expectation from reading the documentation that _every_ row should have a Results value and that most, in this sample anyway, would have AS01 rather than be empty.
My initial thoughts were the problem was because of the 64-bit, but I repeated the process on 32-bit with the same results.
Is an empty Results field equivalent to AS01 code? Or is there an issue I'm missing?
|
|
Groups: Administration
Posts: 16
|
Hi Jeff, Yes the results property should return at least one result for every record, An AS01 signifies the Full Address was verified and should be reflected as the Output result... 1. Depending how you have defined the Output variables, you may need to redefine as varchar or rtrim the results ie.. UPDATE LIST SET Address_Output = rtrim(@Address), etc. Can you 'print' the Output Results to the SQL Results pane. We want to see if the Object is not returning anything, or if it is a table update issue. 2. Are you using our sample code and sample data? Sound like it, but want to be sure. Please pass along your script and if using own data the sample addresses which are not returning any results. 3. What version of the Object are you using? tim@melissadata.com
|
|
Groups: Member
Posts: 6
|
1. I believe that the address/city/zip variables (including DPVfootnotes, statuscode, suitestatus, ErrorCode, ErrorString) ARE being updated/changed correctly. The only problem that I can see is is that the Results property is not returning anything when the result should be AS01. That is, when ErrorString = 'No Error" Results = "", but when ErrorString = "Range Error" or "Unknown Street", Results returns "AE10" and "AE02" respectively.
2. I initially uncovered the issue with some of our SQL scripts, but since I was able to reproduce w/ the scripts provided by MelissaData (CreateList and sp_VerifyAddress) that's what I'm using to discuss the issue. sp_VerifyAddress defines it's @Results output variable as CHAR(25).
3. 4.0.1.1492
Below is partial output when adding a line to print the results property:
Build Number=1492 DEMO
Database Date=1/15/2010
Database Expiration Date=4/30/2010
Results:
Results:
Results:
Results:
Results:
Results:
Results:
Results:
Results:
Results: AE10
Results:
Results:
Results:
Results:
Results:
Results: AE02
|
|
Groups: Member
Posts: 6
|
Similarly, in our large dataset (apx 250,000 address records nationwide) the only AS codes returned are AS14 and AS15. All others are blank or have AE codes:
Results Count
<empty> 245345
AE01 99
AE01,AE07 1
AE02 7033
AE02,AE07 4
AE03 123
AE04 83
AE05 200
AE06 1
AE07 2
AE10 2420
AS14 3940
AS14,AE05 1
AS15 884
AS15,AE05 2
|
|
Groups: Member
Posts: 6
|
In spite of any official acknowledgment, for anyone else experiencing this issue, it does look like it's been resolved in Build #1567.
|
|
Groups: Member
Posts: 6
|
Never mind, it's still not working quite right. While you do get AS01 codes now, you don't get AS14 (SuiteLink) or AS15 (SuiteFinder) codes.
In fact, it looks like if you get AS01 back, that's all you get... which is unfortunate, because I believe the only way to determine whether a suite was added through SuiteFinder v. SuiteLink is from the Results property. Now you might know a suite was appended (via the SuiteStatus property), but you don't know from what Suite add-on the name was matched to.
AE01 99
AE01,AE07 2
AE02 8024
AE02,AE07 4
AE03 130
AE04 81
AE05 206
AE06 1
AE08,AS02 7804
AE09,AS02 20055
AE10 2555
AS01 222339
|
|
Groups: Administration
Posts: 16
|
Are you using a demo or licensed version? From a previous entry you were using 1492 DEMO. With the current build - 1567, demo mode will not return AS14 or AS15. Please obtain a valid license string. Also, make sure your code has the paths to the DPV, SuiteLink and SuiteFinder set.
|
|
|
Guest |
