How can we help you today?
Problem using the same alias to match on two consecutive rows
7 CommentsSorted by Oldest First
Hi Tom,
Do these aliases already exist on the records or are you adding them new? Are you using the Record Type of "Constituent Alias - Add" or "Constituent Alias - Match or Add"?
Thank you,
Amanda
Omatic Software
Do these aliases already exist on the records or are you adding them new? Are you using the Record Type of "Constituent Alias - Add" or "Constituent Alias - Match or Add"?
Thank you,
Amanda
Omatic Software
Hi Amanda,
All the aliases will exist, as they will have been added in a preceding import. Specifically, all those aliases listed in the exception file existed (once and only once) in the database at the point of the import. Also, I've double checked that we're using "Match or Add".
It occurs to me that I might not have been comprehensive in my description of what we're trying to do. The import file has multiples lines per order, with each line having a customer ID that we're using as an alias. This means that the line 1 and line 2 will (for instance) both try to match to the same alias. Something like this:
Where the final column denotes whether it successfully imported or not. I notice the following:
* <b>Even numbered lines are throwing exceptions</b>
* This happens when the alias was successfully matched on the previous line (e.g. row #2 and #1)
* This also happens when the alias has not appeared previously in the file (e.g. row #10)
* <b>Odd numbered rows import successfully</b>
* This happens when the alias was successfully matched on the previous line (e.g. row #5 and #4)
* This also happens when the alias has not appeared previously in the file (e.g. row #7)
In other words, there seems to be absolutely no link between whether the alias has previously appeared (and been matched successfully) and whether an exception is thrown. Conversely, there is a perfect link between the number of the line in the file. To me this seems to strongly suggest a quirk in the way that ImportOmatic is using aliases to match. Perhaps an issue with the way the search is reset between rows?
Anyway, just my 2c. Keen to hear your thoughts.
All the aliases will exist, as they will have been added in a preceding import. Specifically, all those aliases listed in the exception file existed (once and only once) in the database at the point of the import. Also, I've double checked that we're using "Match or Add".
It occurs to me that I might not have been comprehensive in my description of what we're trying to do. The import file has multiples lines per order, with each line having a customer ID that we're using as an alias. This means that the line 1 and line 2 will (for instance) both try to match to the same alias. Something like this:
+-------+--------------+-------------+---------------------------------------+-----------+ | Row # | Alias | Line Number | Item Description | Imported? | +-------+--------------+-------------+---------------------------------------+-----------+ | 1 | ARUK00009654 | 1 | ARUK Pin Badge | TRUE | | 2 | ARUK00009654 | 2 | Postage | FALSE | | 3 | ARUK00009655 | 1 | ARUK Pin Badge | TRUE | | 4 | ARUK00009655 | 2 | Coconut and Lime Shower Gel | FALSE | | 5 | ARUK00009655 | 3 | Orange and Cinnamon soap | TRUE | | 6 | ARUK00009655 | 4 | Postage | FALSE | | 7 | ARUK00009658 | 1 | ARUK Embroidered T-shirt - Small | TRUE | | 8 | ARUK00009658 | 2 | ARUK Embroidered Hoodie - Small | FALSE | | 9 | ARUK00009658 | 3 | Postage | TRUE | | 10 | ARUK00009659 | 1 | ARUK Pin Badge | FALSE | | 11 | ARUK00009659 | 2 | Postage | TRUE | | 12 | ARUK00009660 | 1 | Grow yourown Venus Fly Trap | FALSE | | 13 | ARUK00009660 | 2 | Postage | TRUE | | 14 | ARUK00009661 | 1 | Coconut and Lime Shower Gel | FALSE | | 15 | ARUK00009661 | 2 | Postage | TRUE | | 16 | ARUK00009662 | 1 | ARUK Pin Badge | FALSE | | 17 | ARUK00009662 | 2 | Postage | TRUE | | 18 | ARUK00009663 | 1 | ARUK Pin Badge | FALSE | | 19 | ARUK00009663 | 2 | Postage | TRUE | | 20 | ARUK00009728 | 1 | ARUK Embroidered T-shirt - Large | FALSE | | 21 | ARUK00009728 | 2 | Postage | TRUE | | 22 | ARUK00009734 | 1 | ARUK Embroidered Hoodie - Extra Large | FALSE | | 23 | ARUK00009734 | 2 | Postage | TRUE | | 24 | ARUK00005855 | 1 | ARUK Pin Badge | FALSE | | 25 | ARUK00005855 | 2 | Large ARUK juco bag | TRUE | | 26 | ARUK00005855 | 3 | Postage | FALSE | +-------+--------------+-------------+---------------------------------------+-----------+
Where the final column denotes whether it successfully imported or not. I notice the following:
* <b>Even numbered lines are throwing exceptions</b>
* This happens when the alias was successfully matched on the previous line (e.g. row #2 and #1)
* This also happens when the alias has not appeared previously in the file (e.g. row #10)
* <b>Odd numbered rows import successfully</b>
* This happens when the alias was successfully matched on the previous line (e.g. row #5 and #4)
* This also happens when the alias has not appeared previously in the file (e.g. row #7)
In other words, there seems to be absolutely no link between whether the alias has previously appeared (and been matched successfully) and whether an exception is thrown. Conversely, there is a perfect link between the number of the line in the file. To me this seems to strongly suggest a quirk in the way that ImportOmatic is using aliases to match. Perhaps an issue with the way the search is reset between rows?
Anyway, just my 2c. Keen to hear your thoughts.
Table formatting gone wonky, so have a pastebin: http://pastebin.com/KJx8g0x2
Tom,
What version of IOM are you running? We recently updated how alias matching is working in IOM version 3.2.1. You can find the latest version (now 3.2.2) here.
Please let me know if you're still seeing the strange behavior.
Thanks,
Amanda
Hi Amanda,
We updated to 3.2.2.1 yesterday based on your post. (We only moved up to 3.2.2 on Monday!) This seems to have fixed some of our imports, but not all of them. Those that appear to be fixed use the alias in conjunction with some bio details (name etc.). The import most notably resistant to being fixed is the one I refer to in my first posts; an import that relies entirely on the alias to match. Could this be a factor?
Cheers,
Tom
We updated to 3.2.2.1 yesterday based on your post. (We only moved up to 3.2.2 on Monday!) This seems to have fixed some of our imports, but not all of them. Those that appear to be fixed use the alias in conjunction with some bio details (name etc.). The import most notably resistant to being fixed is the one I refer to in my first posts; an import that relies entirely on the alias to match. Could this be a factor?
Cheers,
Tom
Hi Tom,
On the Constituents>ID Matching screen, do you have it set to Continue processing the data row? This will have IOM perform a duplicate search if there are multiple records with a matching alias.
Hi Sue,
Thanks for the suggestion. It actually did work (which is the important thing!), but I can't understand why, as there weren't duplicate aliases in the first place. Moreover, there aren't any other fields to match on in this file - only the alias ties the row to a constituent. To a neophyte like me, the top option looks like it best matches my situation.
Anyway, for any future adventurers, I did as Sue suggests, then fiddled with the duplicate search options. Specifically, I told it to look for duplicates and to auto-pick if in cases of an alias match.
Thanks again Sue!
Tom
Thanks for the suggestion. It actually did work (which is the important thing!), but I can't understand why, as there weren't duplicate aliases in the first place. Moreover, there aren't any other fields to match on in this file - only the alias ties the row to a constituent. To a neophyte like me, the top option looks like it best matches my situation.
Anyway, for any future adventurers, I did as Sue suggests, then fiddled with the duplicate search options. Specifically, I told it to look for duplicates and to auto-pick if in cases of an alias match.
Thanks again Sue!
Tom
Help Desk Software
by Freshdesk Support Desk
Tom Wright
Hi guys,
Just run into a sticky issue. I'm adding order lines to a constituent using alias matching and alternate lines within the same order are throwing an exception:
Line 2: Multiple records were found for the specified alias: 'ARUK00009654'
Line 4: Multiple records were found for the specified alias: 'ARUK00009655'
Line 6: Multiple records were found for the specified alias: 'ARUK00009655'
Line 8: Multiple records were found for the specified alias: 'ARUK00009658'
Line 10: Multiple records were found for the specified alias: 'ARUK00009659'
Line 12: Multiple records were found for the specified alias: 'ARUK00009660'
Line 14: Multiple records were found for the specified alias: 'ARUK00009661'
Line 16: Multiple records were found for the specified alias: 'ARUK00009662'
Line 18: Multiple records were found for the specified alias: 'ARUK00009663'
Line 20: Multiple records were found for the specified alias: 'ARUK00009728'
Line 22: Multiple records were found for the specified alias: 'ARUK00009734'
Line 24: Multiple records were found for the specified alias: 'ARUK00005855'
Line 26: Multiple records were found for the specified alias: 'ARUK00005855'
I've doubled checked - each of these aliases only appears once in the database. Also, it's interesting that odd-numbered lines are importing fine with the same alias. Any idea what's going on here?
Cheers,
Tom