What does it mean "whenever sqlerror exit 9"? - sql

What does whenever sqlerror exit 9 mean?
And does the number 9 represent anything? I was thinking maybe it's a sqlerror code but I couldn't find a sqlerror code with a number 9.

Typically exiting 0 means success and non-zero means an error. The number of the exit code refers to where the error occurred, and is programmer-defined. Perhaps your program would exit 1 if login failed, 2 if a query returned no rows where at least one was expected, etc. A wrapper program can call this one, then use the return code to see if it ran successfully or not. If not, you know where in the code it failed by the number. Used as you are dealing with, they are called magic numbers. Who knows what they mean as apparently the original developer never at least defined them in a comment. Now you know why magic numbers should be avoided. Instead, define return codes as constants with a meaningful name at the top of your program, then refer to them by that name when used. Whoever maintains the code after you will sing your praises instead of cursing your existence! In Oracle PL/SQL for instance, I'd do something like this:
...
-- Define return codes.
ERR_NOLOGIN CONSTANT INTEGER := 1;
ERR_NOROWS CONSTANT INTEGER := 2;
ERR_TOO_MANY_ROWS CONSTANT INTEGER := 3;
...
-- Then in your error handing:
WHENEVER ERROR EXIT ERR_NOLOGIN; -- No magic number makes for
-- easier to read code.
...

Related

Pinescript v5 'while' loop

My general understanding of a basic while loop (in other languages) is the while loop will break out itself when the variable is no longer true. This does not seem to be happening in Pine Script v5.
Example:
(_RSI is less than _Min_RSI) and (_VOL is greater than _Min_VOL and less than _Max_VOL)
_switch = 0
while _switch > -1
_switch := ( (_RSI >= _Min_RSI and _RSI <= _Max_RSI) ? 1 : -1 )
// While loop should break out automatically after this line if _switch equal to -1
_switch := ( (_VOL >= _Min_VOL and _VOL <= _Max_VOL) ? 1 : -1 )
break
When _RSI is less than _Min_RSI, _switch is correctly set to -1. But, the while loop does NOT break out automatically.......
Instead, it continues to the _VOL line. In essence the overall output is an OR whereas I'm expecting AND.
Above is a sample. The actual code has 50+ checks, for (each of) 10 time-frames. Originally I was using 50 if statements, but thought the while loop would help performance.
Seems the only workaround is to evaluate (and break out after) each line, which kinda defeats the purpose of using a while loop in the first place.
What am I doing wrong? Or does the while loop simply work differently in PS vs other languages?
Thanks
Answer from TradingView Support.
Correct, as we said in the previous post when the 'while' expression
is checked, it goes into the 'while' scope and executes the code
block, if the expression is changed from inside the local block it
will only be re-checked on the next iteration of the script, but it
will not break automatically in the middle of the local scope. If you
want to stop the loop in the middle - use the 'break' keyword after
re-assigning the value of the expression.
Clear.

Turbo C++ : while(fin) vs while(!fin.eof())

I was told that I should be using while(fin) instead of while(!fin.eof()) when reading a file.
What exactly is the difference?
Edit: I do know that while(fin) actually checks the stream object and that when it becomes NULL, the loop breaks and it covers eof and fail flags.
But my course teacher says that fin.eof() is better so I need to understand the fundamental operation that's going on here.
Which one is the right practice?
Note: This is not a duplicate, I need assistance in Turbo C++ and with binary files.
I'm basically trying to read a file using a class object.
First of all I am assuming fin is your fstream object. In which case your teacher would not have told you to use while(fin.eof()) for reading from file. She would have told to use while(!fin.eof()).
Let me explain. eof() is a member of the fstream class which returns a true or false value depending on whether the End Of File (eof) of the file you are reading has been reached. Thus while eof() function returns 0 it means the end of file has not been reached and loop continues to execute, but when eof() returns 1 the end of the file has been reached and the loop exits.
while(fin) loop is entered because fin actually returns the value of an error flag variable inside the class object fin whose value is set to 0 when any function like read or write or open fails. Thus the loop works as long as the read function inside the loop works.
Personally I would not suggest either of them.
I would suggest
//assume a class abc.
abc ob;
While(fin.read((char*)&ob, sizeof(ob)))
{}
Or
While(fin.getline(parameters))
{}
This loop reads the file record inside the loop condition and if nothing was read due to the end of file being reached, the loop is exited.
The problem with while(!fin.eof()) is that it returns 1 if the end of file has been reached. End of file is actually a character that is put at the end of the file. So when the read function inside the loop reads this character and sets a variable eof to 1. All the function actually does is return this value.
Thus works fine when you are reading lines in words but when you are reading successive records of a class from a file, this method will fail.
Consider
clas abc
{}a;
Fstream fin("file");
While(!fin.eof())
{
fin.read((char*)&a,sizeof(a));
a.display(); // display is a member function which displays the info }
Thus displays the last record twice. This is because the end of file character is the character after the last byte of the last record. When the last is read the file pointer is at the eof byte but hasn't read it yet. So it will enter the loop again but this time the eof char is read but the read function fails. The values already in the variable a, that is the previous records will be displayed again.
One good method is to do something like this:
while ( instream.read(...) && !instream.eof() ) { //Reading a binary file
Statement1;
Statement2;
}
or in case of a text file:
while ( (ch = instream.get()) && !instream.eof() ) { //To read a single character
Statement1;
Statement2;
}
Here, the object is being read within the while loop's condition statement and then the value of eof flag is being tested.
This wouldn't result in undesired outputs.
Here we are checking the status of the actual I/O operation and the eof together. You may also check for the fail flag.
I would like to point out that according to #RetiredNinja, we may only check for the I/O operation.
That is:
while ( instream.read(...) ) { //Reading a binary file
Statement1;
Statement2;
}
A quick and easy workaround that worked for me to avoid any problems when using eof is to check for it after the first reading and not as a condition of the while loop itself. Something like this:
while (true) // no conditions
{
filein >> string; // an example reading, could be any kind of file reading instruction
if (filein.eof()) break; // break the while loop if eof was reached
// the rest of the code
}

how can i use wexitstatus to get the value more than 255

I can just speak a little English so I hope you can understand what I said.
I fork a child process , then I do ADD in child process. EX: 56+48=104
If the value lower than 255 , I can use "wexitstatus(status)" to get the answer.
But if the value higher than 256, it would be wrong !
How can I do?
If the program returns an exit code > 255, the program is simply wrong and needs to be fixed. That's against Unix standard. If you're not using standard Unix, you're probably going to need specialist help from within your organisation contacts.
From manpage for wait():
WEXITSTATUS(stat_val)
If the value of WIFEXITED(stat_val) is non-zero, this macro evaluates to the low-order 8 bits of the status argument that the child process passed to _exit() or exit(), or the value the child process returned from main().
It's limited to 8-bits, which means 1 byte, which means the int from WEXITSTATUS can only range from 0-255. In fact, any Unix program will only ever return a max of 255.
Additionally, many OS's/programs reserve > 127 for system designated codes, so you shouldn't even use anything above that.
If you need more return codes than 126 (since 0 is no error), consider writing it to STDOUT and hooking that.

MATLAB Genetic Algorithm "Subscripted assignment dimension mismatch" Error

When trying to use the Genetic Algorithm solver in MATLAB, I'm getting the following "Subscripted assignment dimension mismatch" error: Error Message Pastebin
Now, it says the error has to do with the fitness function at the end, but when I test my fitness function separately, it works without errors. I can also link the code for my fitness and constraint functions if that would help.
Thank you very much!
I think I see what is happening... Because one of the appendages to CDraft is inside the if, you don't always return the same length vector - i.e., you return a constraint vector the first time, it preallocates a matrix for your constraint output, then the next time round you give it back something that doesn't fit in this matrix, so you get the error.
The clue is in the error stack: at the top of the stack we have
Subscripted assignment dimension mismatch.
Error in C:\Program
Files\MATLAB\R2012b\toolbox\globaloptim\globaloptim\private\gaminlppenaltyfcn.p>i_convectorizer
(line 135)
Clearly this is not a function you've written, and inspecting your function there's nothing that should cause this error. The end of the error gives another clue
Caused by:
Failure in initial user-supplied fitness function evaluation. GA cannot continue.
The ga function is reporting an error in the bit of the code that handles user-supplied constraints. It is likely that this whole bit of code (the call to the user-supplied function and other associated lines) are all within one try...catch statement that returns this error. Something like this:
try
c = userConFun(x);
if isempty(cHistory)
cHistory = zeros(length(c), 1000); % or whatever
end
cHistory(:, currentIterationIndex) = c;
catch err
error('Failure in user-supplied fitness function blah blah blah');
end
Consequently, it looks like the error came from your function, even though it occurred after your function returned.

Parameter 3 is not constant in call of system task $fwrite

I am using Xilinx ISE 10.1 to run some verilog code. In the code I want to write the register values of 3 registers in a file, cipher.txt. The following is the code snippet:
if (clk_count==528) begin
f1 = $fopen("cipher.txt", "w");
$fwrite(f1, "clk: %d", clk_count[11:0]);
$fwrite(f1, "plain: %h", plain[31:0]);
$fwrite(f1, "cipher: %h", cipher[31:0]);
$fclose(f1);
end
At the end of execution, the contents of cipher.txt is found as:
clk: %dplain: %hcipher: %h
There is no other error encountered, but a warning comes up corresponding to the 3 fwrite's:
Parameter 3 is not constant in call of system task $fwrite.
Parameter 3 is not constant in call of system task $fwrite.
Parameter 3 is not constant in call of system task $fwrite.
The values of the registers clk_count and cipher change on every clock cycle (value of register plain remains constant throughout), and the values are written to cipher.txt when clk_count equals 528 (indicated by the if statement)
Can anybody provide some insight and/or help me get past this hurdle?
Thanks.
It appears that ISE expects the arguments to $fwrite to be constant. The warnings are referring to clk_count[11:0], plain[31:0], and cipher[31:0], which are not constant. By definition they are changing each cycle so they are not known at compile time. This also explains why they are not printing and you are seeing %d and %h in the output.
There is nothing to my knowledge in the Verilog spec that requires the arguments to $fwrite be constant. The same code works as expected with Cadence Incisive. My guess is that it's a limitation of ISE, so you may want to check with Xilinx.
Possible work-arounds:
1) Use $swrite to create a string with the proper formatting. Then write the string to the file.
2) Try using an intermediate variable in the calls to $fwrite. Maybe the part-selects are throwing it off. e.g.
integer foo;
foo = clk_count[11:0];
$fwrite(... , foo , ...);
Either of those might work, or not.
Out of curiosity, if you remove the part-selects, and try to print clk_count without the [11:0] , do you get the same warnings?