I've had a multiple cases where MongoDB failed to properly run a command. First it happened with one of my Python scripts (it's never failed before with the same code). Something broke because the command failed to run properly. I got suspicious and ran it by hand in NoSQLBooster. I got a response with no error. It said acknowledged: true, matchedCount: NaN, and modifiedCount: NaN. I ran it again without changing the command and it worked. Is this something that can happen regularly with MongoDB? Do I need to build in logic to ensure my commands went through properly?
In case it's relevant, here's the command:
db.users.updateMany({}, {"$set": {"f1.f2": 0}})
While it is possible that there is a server bug that caused a command to not be executed, or its outcome to not be reported correctly, it is far more likely that either:
You, or a library you are using, didn't check the execution result and filled in some placeholder values that you think came from the server.
You checked the execution result but didn't do it correctly. The driver is supposed to handle this for you, but you can review server command documentation for the way that that particular command signifies failure. There are quite a few ways that many commands can fail (write concern errors, write errors, etc.).
Updating zero documents is not an error nor is it a failure in the server (you could've had zero documents in the collection to begin with, or none matched the filter you provided).
Related
I realize this is a bad question, but I don't know where else to turn.
can someone point me to where I can find the list of reports failure codes for IBM? I've tried searching for it in the IBM documentation, and in general google search, but this particular error is unique and I've never seen it before.
I'm trying to find out what code 262148 means.
Background:
I built a datastage job that has:
ORACLE CONNECTOR --> TRANSFORMER -> HIERARCHICAL DATA
The intent is to pull data from a ORACLE table, and output the response of the select statement into a JSON file. I'm using the HIERARCHICAL stage to set it. When tested in the stage, no problems, I see the JSON output.
However, when I run the job, it squawks:
reports failure code 262148
then the job aborts. There are no warnings, no signs, no errors prior to this line.
Until I know what it is, I can't troubleshoot.
If someone can point me to where the list of failure codes are, i can proceed.
Thanks!
can someone point me to where I can find the list of reports failure codes for IBM?
Here you go:
https://www.ibm.com/support/knowledgecenter/en/ssw_ibm_i_73/rzahb/rzahbsrclist.htm
While this list does not list your specific error code, it does categorize many other codes, and explains how the code breakdown works. While this list is not specifically for DataStage, in my experience IBM standards are generally compatible across different products. In this list every code that starts with a 2 is a disk failure, so maybe run a disk checker. That's the best I've got as far as error codes.
Without knowledge of the inner workings of the product, there is not much more you can do beyond checking system health in general (especially disk, network and permissions in this case). Personally, I prefer to go get internal knowledge whenever exterior knowledge proves insufficient. I would start with a network capture, as I'm sure there's a socket involved in the connection between the layers. Compare the network capture from when the select statement is run from the hierarchical from one captured when run from the job. There may be clues in there, like reset or refused connections.
We're using phinx-db for migrations.
I'm trying to find out what happens if a query fails using the execute command. The documentation is not clear about this.
In other words, if I call $this->execute("my sql statement"); and the statement fails, will execute throw an exception? Or will it just fail silently with zero rows updated?
With batch executions any failure is silent, but the documentation does say what happens for a single statement.
Using with PDO it throws a exception.
But I think it may vary depending on which adapter you are using.
In Netlogo Behavior space, if one of the runs is throwing an error, how to skip that run and ask netlogo to proceed with the next run?
Is it even possible?
From the docs,
If you do want spreadsheet output, note that if anything interrupts
the experiment, such as a runtime error, running out of memory, or a
crash or power outage, no spreadsheet results will be written. For
long experiments, you may want to also enable table format as a
precaution so that if something happens and you get no spreadsheet
output you'll at least get partial table output.)
So, I'll assume this isn't possible and the best way to fix this would be to handle the situation where your code has an error. Alternatively, you could use the carefully command to handle the error messages.
I'm running jobs through Datastage with the DELETE then INSERT connector. I'm having several jobs failing for this error:
DB2_Connector: DB2 reported: SQLSTATE = 02000 Native Error Code = 100, Msg = IBM[CLIDriver][DB2/NT64] SQL01000W No row was found for FETCH, UPDATE, or DELETE
When I run the delete statement in Data Studio directly in DB2, it gives this same error so I know it's a DB2 error, not a Datastage error.
Is there anyway to supress the message in Datastage or when I run the statement in DB2 is there anyway I can keep that message from coming up? It's stopping my DS jobs now with a Fatal error and not continuing to load.
There has got to be a way to turn off the message. I know in SQL Server if no rows are found it does not give this error, it just says zero or doesn't return records but in DB2 this error is coming up and I'm not sure if there is a way to turn it off.
First of all, you seem to be confused about precisely what an error is, and what a message is.
An error is when something goes wrong.
A message is when some piece of software is kind enough to let you know that something went wrong.
From this it follows that suppressing a message has no bearing whatsoever on the actual error. Your software is not failing because of the message, your software is failing because something is going wrong. Receiving a message about it is actually a good thing: the alternative would be your software failing without you being given any clue whatsoever as to what is going wrong.
Suppressing or otherwise ignoring errors is like hiding your head in the sand: you are still going to end up as meal.
So, what you need to make go away is the error, not the message.
Which means that you have to figure out what you did wrong.
Luckily, you have the message giving you a hint as to what you did wrong, though you have to keep in mind that messages are sometimes misleading.
SQLState 02000 is not an error, it is a warning. (And note that DB2_Connector is not saying ERROR!!!1!:, it is saying DB2 reported:.) Luckily JDBC issues warnings when it detects situations that might be indicative of errors; there is a lot of software out there that ignores JDBC warnings, (essentially hiding your head in the sand for you, how nice,) but luckily DB2_Connector reports them.
What this means is that one of two things is going wrong:
Either your assumption that it is okay if no rows are found is wrong, and the fact that no rows were found is the cause of your problem, which means that you have to somehow make sure that some rows are found, or
Your assumption that it is okay if no rows are found is correct, in which case the warning reported has absolutely nothing to do with the problem at hand, so it can safely be ignored, and you have to look at the problem elsewhere.
I'm using SQL Server Express 2008 and I'm doing a bulk insert of data. I'd like to have more verbose error messages, ideally printing the data that failed to be inserted. Is that possible?
It is possible, but it can require a lot of effort to to do this--I recall working on a subsystem for a few days before I got it to do everything it needed to do. I believe this is one of the (few but still too many) places where, upon hitting an error, SQL will return two (2) error messages back-to-back, the second message is vague and indistinct, and all the error handling functions can only access info pertaining to that second lame message, and not the first one where the real info is. I don't have the code in front of me, but the logic was something like:
Use the "errorfile" option on BULK INSERT to generate an error file IF the bulk insert fails
TRY/CATCH the bulk insert call, and carefully check the returned error number
If the error is the appropriate type, open and read the contents of the file to determine what went wrong where, and build your error message around that
Awkward as anything, but ultimately it worked out pretty well. So long as the drive+path+filename you were inserting from didn't exceed 128 characters (in SQL 2005, and I just bet they didn't fix that in 2008.) I do not count Bulk Insert as one of my favorite commands.