You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Maybe I'm misreading things, but it seems to me that when --trace-silent (default false) was refactored to --trace-to-file (default true) in 3afaf2d we lost the ability to turn it off? Nothing I'm trying seems to work, whether the flag is present or not, with a subsequent parameter of "false" or not, log files are generated.
In my case, I was trying to launch dozens of yuniql instances concurrently (via powershell's Start-ThreadJob) and the naming convention on the log files (date and time to the second) would generate synonyms, which caused problems downstream. I've worked around it by pre-creating folders for every database being upgraded, forcing each instance to run in its own folder using --trace-to-directory, and then deleting the folders when done, which does work for me.
The text was updated successfully, but these errors were encountered:
@pwilliams906, interesting find and thank you for reaching out. Sounds like a bug and I'll try to find time to repro and fix. Possible patch release would after Easter holidays Apr 20+. Glad you still manage to find a work around, sorry for inconvenience.
P.S. Please star our repo ICYMI. It goes a long way in getting better stats and helping more people discover this tool :) Thanks!
Maybe I'm misreading things, but it seems to me that when --trace-silent (default false) was refactored to --trace-to-file (default true) in 3afaf2d we lost the ability to turn it off? Nothing I'm trying seems to work, whether the flag is present or not, with a subsequent parameter of "false" or not, log files are generated.
In my case, I was trying to launch dozens of yuniql instances concurrently (via powershell's Start-ThreadJob) and the naming convention on the log files (date and time to the second) would generate synonyms, which caused problems downstream. I've worked around it by pre-creating folders for every database being upgraded, forcing each instance to run in its own folder using --trace-to-directory, and then deleting the folders when done, which does work for me.
The text was updated successfully, but these errors were encountered: