Identical workflows, but only one gives an error - R tool
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Mute
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Notify Moderator
I am testing out a macro to parse pdfs with an R tool, which was working very well until I created a new workflow with the macro and received an error.
After messing around, I have made two simple, identical workflows where one gives an error in the macro from the R tool while the other does not. It is the exact same macro pointing to the exact same pdf. I looked at the XML and that is identical as well, does anyone know if there is something else that could be causing this and how to prevent the error? I'm assuming there is some difference causing it and they are not actually identical, but from what I can tell, they are.
The error is: Error: PDF Reader (10): Tool #4: Error: '\U' used without hex digits in character string starting ""C:\U"
Packaged workflows attached. When I import them, the same thing still happens, tested after restarting my computer as well. Any guidance would be appreciated, thanks!
Version: 2023.1.1.437 Patch: 9
- Labels:
- Error Message
- Macros
- R Tool
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Notify Moderator
I have the No Error version that works but I wouldn't feel comfortable implementing a tool (the R tool itself, not just this specific macro) in my workflows that I don't know how to troubleshoot, so any guidance or direction even if you don't have the answer would be very helpful, thank you!
Another thing I tested, which brought an error that seems cache related and makes me wonder if this post's is cache related as well (although I'm not sure how creating two identical workflows and one giving an error while the other works would be cache related):
In the Error workflow, I opened the macro and replace the string that contained "C:\U" with something else ("file.pdf") as that was just a place holder to be replaced.
Now the error is "Error: PDF Reader (10): Tool #4: Error: unexpected symbol in "file <- C:\Users"". The string "C:\Users" isn't in the code for the R tool or anywhere else in the macro. I'm not sure how to trouble shoot that either. I can avoid using \U in my R code as that is an R thing or figure out other workarounds, but this seems cache related, which makes me wonder if the original issue is? I'm not sure how that would apply though, as it not a change to a workflow issue. Either way, I restarted Alteryx and my computer and that should have cleared any cache issues.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Notify Moderator
I had some colleagues test that the error workflow did not work and no error workflow did, and they confirmed - is there somewhere outside of the tool configuration or XML code I can look at for differences?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Notify Moderator
Is it because your backslash is being interpreted as an escape character?
But after reading your further comments, your placeholder trick seems to show that the "C:\Users" is still lingering around. Maybe scan through your code once more?
If you have access to AI like poe or copilot, you can try testing and troubleshooting with AI.
Alteryx ACE
https://www.linkedin.com/in/calvintangkw/
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Notify Moderator
I appreciate the response, you're correct in that being what the original error is referring to, it is just that the code in the macro is fixed, and one gives the error and the other doesn't. The update was just to say that clearly there must be a cache I cannot see, and maybe that is why my two identical workflows are giving different outputs. One must have something cached that the other doesn't, as I am positive that there was only the one place that had "file <- C:\Users", as its just a few lines of code. In fact, it was already fixed to be C:\\ instead of C:\, which fixes the error.
All that being said, I don't think there is anything that can be done here, but I feel better knowing that at least
