'max_sp_recursion_depth' variable doesn't appear to set causing "Recursive limit 0 was exceeded" error - sql

Quick note, I know this question has been asked here, but the 'answer' gives an alternative which doesn't involve recursion. I want to get recursion working. Here's some code I wrote to demonstrate the problem:
CREATE OR REPLACE PROCEDURE `test` (x INT)
BEGIN
SHOW GLOBAL VARIABLES LIKE 'max_sp_recursion_depth';
IF x = 0 THEN
SELECT 1;
ELSE
CALL `test`(x-1);
END IF;
END
Returns:
+------------------------+-------+
| Variable_name | Value |
+------------------------+-------+
| max_sp_recursion_depth | 64 |
+------------------------+-------+
1 row in set (0.001 sec)
ERROR 1456 (HY000) at line 43 in file: 'workspace.sql': Recursive limit 0 (as set by the max_sp_recursion_depth variable) was exceeded for routine test
What I've tried
I will update this as I try more things:
setting the variable via the MariaDB CLI
setting the variable via PHPMyAdmin
restarting MariaDB
restarted the entire server
restarted my computer (currently running in a development environment on my mac) and the variable has reset to 0

SET GLOBAL ...
does not have any effect on the current connection; only future connections. (Exception: Some variables are "only global"; those probably do show up immediately.)
SET SESSION ...
Is what to do to make it work for the current connection.

I added
max_sp_recursion_depth=255
To the my.cnf file and that fixed the issue. Still unclear as to why the variable wasn't set via the command line, but 🤷 it works. Although I am still interested so if anyone sees this and wants to elaborate, you're an amazing human!

Related

Oracle SQLPlus: Echo without line numbers?

I'm working on a solution where several SQL and PL/SQL scripts are being run together, in a batch of sorts, via SQL*Plus.
I'm declaring SET ECHO OFF; and SET ECHO ON; at relevant points in the scripts so as to output relevant code.
Currently the output looks something like this:
SQL> DECLARE
2 ct number := 0;
3 ctChanges number := 0;
4
5 BEGIN
6 select count(*) into ct from ...
7 (...rest of code block...)
"some specific status message"
Commit executed.
We keep this output as a run-log in our build-environment, but can also access it as a plain text file.
One downside of this format however, is that if I'd like to copy a certain section of the code and run it again in an IDE (like Toad or SQL Developer), it's hard to exclude the line numbers.
Is it possible to tell SQL*Plus to output the code as above, but without including the line numbers?
You can use options sqlnumber and sqlprompt:
set sqlprompt ''
set sqlnumber off
SET SQLN[UMBER] {ON|OFF}
SET SQLNUMBER is not supported in iSQL*Plus
Sets the prompt for the second and subsequent lines of a SQL command or PL/SQL block. ON sets the prompt to be the line number. OFF sets the prompt to the value of SQLPROMPT.

How do I reformat v$session.osuser?

I am trying to set up an Oracle WebLogic Datasource for my job. But every time I try to connect to the database, I get this error:
Connection test failed.
Message icon - Error Connection property: format error: Property is 'v$session.osuser' and value is 'Yann (Intern)'
I tried changing my username to "YannIntern" to remove the special characters, but the error is still the same and it also happens when I try to use Oracle SQL Developer. How can I stop the format error?
Java reads this from the user.name property which defaults from the os username. However, this can be overriden by setting -Duser.name=Yann
Here's an example in sqlcl
SQL> select sys_context('userenv', 'os_user') from dual;
SYS_CONTEXT('USERENV','OS_USER')
------------------------------------
klrice
<<< a short command to set java properties >>>
<<< which is the same as a -D property >>>
SQL> set property user.name kris
Setting user.name to kris (klrice)
SQL> #connect-klrice
Connected.
SQL> select sys_context('userenv', 'os_user') from dual;
SYS_CONTEXT('USERENV','OS_USER')
----------------------------------
kris
SQL>
Same happened to me, I have parenthesis in my computer's name. I spent a lot of time researching but finally, I have the solution (I created an account just to answer this haha). To solve this you have to:
-Go to the folder location where you installed SQL Developer.
-Then go to: \ide\bin\ide.conf
-At the end add the following line:
# Custom VM Option
AddVMOption -Duser.name=<YourUsername>
-Save the file, and restart SQL Developer, you will be able to connect and avoid that error message.

How to run SQLite3 'PRAGMA' commands via C-API?

Inside my C-program, I need to run the following pragma command:
const char *sql = "PRAGMA table_info(family)"; /* 'family' is the table name */
But whether i try to run this sql via sqlite3_exec() routine or sqlite3_prepare_v2() routine, my program stops responding/working at Windows command-prompt (it's a simple 'console program' in c-language).
Interestingly, when i run that same pragma sql at command-prompt normally by running the sqlite3.exe itself, it runs just fine and gives following output:
sqlite> pragma table_info(family);
cid name type notnull dflt_value pk
---------- ---------- ---------- ---------- ---------- ----------
0 id INTEGER 0 1
1 name TEXT 1 0
2 nickname TEXT 1 0
3 dob TEXT 1 CURRENT_TI 0
But inside my own c-program it doesn't. I have done a bit research about this problem. Both Googling and SQLite Documentation point towards this page here at the official docs. But unfortunately the given information there hasn't enabled me enough to resolve the problem. How can we successfully run SQLite3 'PRAGMA' commands via C-API?
EDIT: Here are the actual problematic lines of code. OR MCVE
I have found the reasons of my program's failure, and have fixed it (Courtesy of clues and leads in Murphy's answer. But for those interested in reproducing the problem, here are the actual lines of code which were causing program to "crash".
Inside my callback function for sqlite3_exec() routine, I had this piece of code(for-loop) for printing ' ---------- ' characters below column names to mimic ".mode column" & ".headers on" style of output in sqlite3 console.
int h;
for(h=0; h <= (strlen(col_value[i])+5); h++)
printf("-");
The problem was being caused by strlen() while printing 'headers' for PRAGMA sql's result column dflt_value which is null for first three columns in my table. If i stop running strlen() on dflt_value. the program runs fine. Similarly, in sqlite3_prepare_v2() routine the problem was being caused by the following lines:
int h;
for(h=0; h <= (strlen(sqlite3_column_text(stmt, 4))+5); h++)
printf("-");
If i remove or comment these lines, all runs well - albeit without ".headers on" style.
sqlite3_exec() should indeed be the way to go to execute pragma commands. You didn't give a MCVE (shame on you!), but I suspect that you either neglect handling error values, or something else is wrong with your code. You should try debugging it.

TYPO3: SQL error: 'Incorrect integer value: '' for column 'sys_language_uid' at row 1'

I have newly setup TYPO3, but when I try to add/save content, it gives me this error:
SQL error: 'Incorrect integer value: '' for column 'sys_language_uid'
at row 1
The behavior is related to database management systems using strict mode, like MySQL since version 5.7. Disabling strict mode (like provided in the accepted answer) is just a work around.
The real solution would be to explicitly cast values to integer by modifying TCA (table configuration array) for the according field definitions.
for fields of type input that would be setting/extending 'eval' => 'int', see example tt_content.starttime
or in general for all field types it would be to define the default value using 'default' => 0, see example tt_content.sys_language_uid
set this in Localconfiguration.php file
[SYS][setDBinit] = SET SESSION sql_mode=''
For me, after trying different approaches, the solution was:
mysql -u root -p -e "SET GLOBAL sql_mode = 'NO_ENGINE_SUBSTITUTION';"
Then, you can verify that the mode is set by running the following:
mysql -u root -p -e "SELECT ##GLOBAL.sql_mode;"
And you should see:
+---------------+------------------------+
| Variable_name | Value |
+---------------+------------------------+
| sql_mode | NO_ENGINE_SUBSTITUTION |
+---------------+------------------------+
In latest TYPO3 Versions you have to add this in LocalConfiguration.php
'setDBinit' => 'SET SESSION sql_mode = \'NO_ENGINE_SUBSTITUTION\';',
In Typo3 9.5/10.4
It you are not able to change the programming of the used extentions - or change the running mode of mysql server - it might be useful to change the mode of the typo3 connection. You can simply add to youre LocalConfiguration.php.
[DB][Connections][Default][initCommands]='SET SESSION sql_mode = \'\';',

while [[ condition ]] stalls on loop exit

I have a problem with ksh in that a while loop is failing to obey the "while" condition. I should add now that this is ksh88 on my client's Solaris box. (That's a separate problem that can't be addressed in this forum. ;) I have seen Lance's question and some similar but none that I have found seem to address this. (Disclaimer: NO I haven't looked at every ksh question in this forum)
Here's a very cut down piece of code that replicates the problem:
1 #!/usr/bin/ksh
2 #
3 go=1
4 set -x
5 tail -0f loop-test.txt | while [[ $go -eq 1 ]]
6 do
7 read lbuff
8 set $lbuff
9 nwords=$#
10 printf "Line has %d words <%s>\n" $nwords "${lbuff}"
11 if [[ "${lbuff}" = "0" ]]
12 then
13 printf "Line consists of %s; time to absquatulate\n" $lbuff
14 go=0 # Violate the WHILE condition to get out of loop
15 fi
16 done
17 printf "\nLooks like I've fallen out of the loop\n"
18 exit 0
The way I test this is:
Run loop-test.sh in background mode
In a different window I run commands like "echo some nonsense >>loop_test.txt" (w/o the quotes, of course)
When I wish to exit, I type "echo 0 >>loop-test.txt"
What happens? It indeed sets go=0 and displays the line:
Line consists of 0; time to absquatulate
but does not exit the loop. To break out I append one more line to the txt file. The loop does NOT process that line and just falls out of the loop, issuing that "fallen out" message before exiting.
What's going on with this? I don't want to use "break" because in the actual script, the loop is monitoring the log of a database engine and the flag is set when it sees messages that the engine is shutting down. The actual script must still process those final lines before exiting.
Open to ideas, anyone?
Thanks much!
-- J.
OK, that flopped pretty quick. After reading a few other posts, I found an answer given by dogbane that sidesteps my entire pipe-to-while scheme. His is the second answer to a question (from 2013) where I see neeraj is using the same scheme I'm using.
What was wrong? The pipe-to-while has always worked for input that will end, like a file or a command with a distinct end to its output. However, from a tail command, there is no distinct EOF. Hence, the while-in-a-subshell doesn't know when to terminate.
Dogbane's solution: Don't use a pipe. Applying his logic to my situation, the basic loop is:
while read line
do
# put loop body here
done < <(tail -0f ${logfile})
No subshell, no problem.
Caveat about that syntax: There must be a space between the two < operators; otherwise it looks like a HEREIS document with bad syntax.
Er, one more catch: The syntax did not work in ksh, not even in the mksh (under cygwin) which emulates ksh93. But it did work in bash. So my boss is gonna have a good laugh at me, 'cause he knows I dislike bash.
So thanks MUCH, dogbane.
-- J
After articulating the problem and sleeping on it, the reason for the described behavior came to me: After setting go=0, the control flow of the loop still depends on another line of data coming in from STDIN via that pipe.
And now that I have realized the cause of the weirdness, I can speculate on an alternative way of reading from the stream. For the moment I am thinking of the following solution:
Open the input file as STDIN (Need to research the exec syntax for that)
When the condition occurs, close STDIN (Again, need to research the syntax for that)
It should then be safe to use the more intuitive:while read lbuffat the top of the loop.
I'll test this out today and post the result. I'd hope someone else benefit from the method (if it works).