Situation
I am using MongoDB 5.0 community server locally. I am creating with the shell at the moment.
Problem
When I set up validation, and test that validation, I get an error. But the error is collapsed in an [object].
I have searched everywhere online but I cannot figure out how to get "verbose" error logging?
Image of error
This is what I see:
My goal is to see the error details inside the shell.
Related
Environment: Windows 10
IDE: Visual Studio Code
Extensions: Live Server v5.7.5 by Ritwick Dey and Microsoft Edge Tools for VS Code v2.1.0
When I am debugging JavaScript files, if I put a break point in an exported class, I get the error shown in the image bellow.
I cleared the Windows System log, and right after I start debugging and get the error, a new entry is in the Windows system log. This happens every time without fail. The error in the Windows System log is:
The application-specific permission settings do not grant Local Activation permission
for the COM Server application with CLSID
{2593F8B9-4EAF-457C-B68A-50F6B8EA6B54}
and APPID
{15C20B67-12E7-4BB6-92BB-7AFF07997402}
to the user DOMAIN\\local_user SID (S-1-5-21-2158192427-3696246665-2163083460-1135) from
address LocalHost (Using LRPC) running in the application container Unavailable SID
(Unavailable). This security permission can be modified using the Component Services
administrative tool.
My question is how do I fix this issue?
Update 7/26/2022:
If I remove the breakpoint from the constructor of the class and put it elsewhere in the class, it works without any errors. The error occurs if the breakpoint is in the constructor.
I found the answer and it is not anything above.
Well, I finally solved the problem. I am updating this answer so that someone else will know the answer without going down all the wrong paths that I went down. The problems was not any of the tools. The problem was with the code. While technically the code was correct, executing it with a breakpoint caused the error I talked about above. I was able to fix this problem by moving all the class member variables to the top of the class before all member functions. The error only occurs when you add a breakpoint before the member variables are defined. Code analyzers say there is nothing wrong with the code. The error message could be more informative!
If you want to see example code associated with this problem. See this post
We have been running a service using NestJS and TypeORM on fully managed CloudRun without issues for several months. Yesterday PM we started getting Improper path /cloudsql/{SQL_CONNECTION_NAME} to connect to Postgres Cloud SQL instance "{SQL_CONNECTION_NAME}" errors in our logs.
We didn't make any server/SQL changes around this timestamp. Currently there is no impact to the service so we are not sure if this is a serious issue.
This error is not from our code, and our third party modules shouldn't know if we use Cloud SQL, so I have no idea where this errors come from.
My assumption is Cloud SQL Proxy or any SQL client used in Cloud Run is making this error. We use --add-cloudsql-instances flag when deploying with "gcloud run deploy" CLI command.
Link to the issue here
This log was recently added in the Cloud Run data path to provide more context for debugging CloudSQL connectivity issues. However, the original logic was overly aggressive, emitting this message even for properly working CloudSQL connections. Your application is working correctly and should not receive this warning.
Thank you for reporting this issue. The fix is ready and should roll out soon. You should not see this message anymore after the fix is out.
When I run a flow in Tableau Server, it fails with the following error message:
Unfortunately this error is not helpful in understanding the actual cause of the problem.
Is there a way to see the actual underlying error? Or how am I supposed to debug this?
The flow runs fine in my Tableau Prep.
(EDIT: I used state here that I used a different data source to test in prep, but this is no longer true)
Arguably that error log does give you a hint as to what the issue is. The issue is with the Output step. This is most likely due to a permissions error when Tableau Server goes to publish the output since you can do it locally in Tableau Prep.
Are credentials for your flows able to be embedded on server? This will impact whether the output will be accessible. Are all flows run using a service account? Make sure that service account has access to the output location.
If these troubleshooting steps don't work, check the server logs. For this you'll need to check the logs on Tableau Server using the command line to see if there is a more detailed response. If you have the access, run tsm maintenance ziplogs to zip the log files and investigate.
The back up system I am running gives me this error
mysqldump: Got error: 0: when retrieving data from server
I have been looking around and I failed to find another output with error code 0. I do not know if that even matters or not but I thought it would otherwise it would be same number as others. Thats why I made this topic.
Server is CentOs
MySQL version 5.5.33-31.1
What throws me off is that I have another box with same OS and MySQL version and it works fine.
I have been looking at this site for reference but there is no code 0...
Any other information you need, please tell and I will put it here.
After upgrade our IBM System i (aka i5/OS or AS/400) from V5R4 to V7R1, one of our applications that connect to DB2 using ODBC fails with the following error:
Error Code: 69899
SQLSTATE: S1000
[IBM] [System i Access ODBC Driver] [DB2 for i5/OS] PWS0005
Error occurred in the database host server code.
The symptoms are:
In a While / Wend loop a CURSOR is declared, then opens, do fetch(s) and close.
If at any iteration the cursor does not retrieve any rows, in the following iteration the error occurs after declaring the cursor (with a different SQL query) when you try to open it.
First we updated the ODBC driver to the latest version available, but the problem persists.
Because we needed an urgent solution, I solved the problem by making a pre-select to determine if the cursor will return rows, otherwise skip that iteration, this solves the problem for now but does not seem a very elegant solution.
Any idea how to get more information about the error that occurs on the host?
Thank you very much in advance.
Generally speaking, if an error occurs in the server side code, you should call IBM support and report it. They'll ask if you're on the latest cume and probably the latest database group PTFs.
The server runs the ODBC connexion in a job called QZDASOINIT. Since there are probably many connexions to the system, there are probably many QZDASOINIT jobs. To find yours, go to a terminal session and WRKOBJLCK MYPROFILE *USRPRF. You'll be presented with a list of jobs running with your user profile. At least one of them will be the QZDASOINIT job you're looking for. Use option 5 to look at the job, then option 10 to see the job log. Press F10 to see the detailed messages and F18 to go to the bottom (most recent) entries.
If the error was so severe that the server job terminated abnormally, there won't be a lock on your user profile. Instead, go to the spooled job log by using WRKSPLF.
IBM have been logging some SQL internal errors since V5R4. select * from qrecovery.qsq901s; to see any SQLCODE -901 errors.
Make sure that you have installed the latest fix pack for the latest version of System I Access
I've had this error before and it was caused by a syntax error in the connection string. It was a setting that was insignificant in older versions of the OS and more significant in newer versions, but did not cause the connection itself to fail so it was hard to track down.
For example: Port Number:8471 had a spelling mistake and was Porte Number:8471 hard to spot but once found, it fixed the problem for me. Basically everything past this part of the connection got ignored.
Wanted to add another solution to this problem. The SQL Packages that exist on your system get corrupted after/and or during upgrades. You MUST delete these packages after an upgrade. This will get rid of the old packages and will allow the system to recreate the packages at the new OS version level. When deleting SQL packages some connections/jobs may have locks on those packages so you might have to shut host services down. Use the DLTSQLPKG command to do the delete. In v7r2 and higher there are some additional steps to do as IBM changed somethings when it comes to packages you can find the info here http://www-01.ibm.com/support/docview.wss?uid=nas8N1015556
Or tell your ODBC/JDBC/.Net Data adapter/provider to not use packages. This is probably less desirable as there are performance benefits to packages.