Solved! Go to Solution.
Having a similar issue but different.
At one point we were getting the error 'Error(No module named 'pymssql._pymssql')" when we were importing with "import pymssql". That was our mistake because we were building on Windows and deploying to Linux (thank you @Mike_L for the above post reminding us of that). It took a while to fix because even when we redeployed it showed that error until we deleted everything and did a fresh deployment, then had to let the ActiveGate run it, fail, then it self restarted, then flipped to 'OK' status on its own. (FYI....this error does show up ever so often still).
So, now we're getting a new error caught in our exception handler: module 'pymssql' has no attribute 'connect'
Online community posts suggested we use a capital 'Connect'. That didn't make a difference at all. We then ran the code on the AG using the Simulator, it runs, but not when we deploy it.
Has anyone encountered 'module 'pymssql' has no attribute 'connect'?
When you run oneagent_build_plugin, do you do that with the 64 bit version of Python 3.8? Also, make sure that you do it on the correct OS, same as the AG/OA where it will run.
Also, if you do the change such as connect and Connect, make sure that you bump the version of the plugin.json file on the AG/OA.
Ok, have some updates. We got it all working but some things that may help others.
The key for us was that we updated from Ubuntu 20 to 22. What we didn't realize was that the update would automatically increase Python from 3.8.5 to 3.10. We tried to downgrade Python on Ubuntu 22 but that's not so easy to get Python 3.8 on Ubuntu 22. So we dropped back down to Ubuntu 20 in the end.
Yes, building the Extension on the exact same infrastructure as your Production ActiveGate is critical. We all know build on Windows for Windows and build on Linux for Linux but to be safe, just build on the same OS version even as your intended Production AG. Don't even try to mix flavors of Linux, you may get lucky but you may also end up with really quirky issues.
When in doubt, interrogate the version of your extension deployed into /opt/dynatrace/remotepluginmodule/plugin_deployment. We found packages in there with wrong version numbers, some were Windows instead of Linux, we found things put in some odd places. It all had to do with the many ways we were attempting to resolve our issues, ultimately we cleared it all out, got a fresh OS, and rebuilt everything. And it worked. But looking into the deployed extension really shined the spotlight on what was wrong and then made it clear on how to fix it.
Good luck to anyone else should you have found this article via a google search. pymssql does appear to be alive and regularly updated, it does work. I do look forward to Extension 2.0 Python and maybe moving to pyodbc instead in the future.