đź‘‹ Use this site to provide feedback and ideas for all Nintex Products. See our post on Nintex Community "Welcome to Nintex Ideas" for more details on Nintex Ideas, how an idea is handled by our product teams and more!
If you have questions about Nintex Ideas, please contact ideas@nintex.com
If you require support, please visit Nintex Customer Central
If you have a sales inquiry, please contact sales@nintex.com
Wouldn't someone finally like to take this idea and do something about those SQL procedures?
The problem is that everything happens in a single transaction, during which indexes in the archive database are dropped, then records are loaded from the main K2 database into the archive, followed by the deletion of what was transferred, and finally, the indexes in the archive database are rebuilt. That transaction is incredibly large and time-consuming. When I feed those SQL queries to an AI to find bottlenecks that could be improved, it identifies them immediately.
Archiving with the current script is, I’d say, a real pain if you’re trying to do it on a database that’s several hundred GB in size.