We Keep Coding

Why is "insert into" inside stored procedure not working from python?

I wrote a stored procedure in SQL Server that gets passed 4 parameters. I want to check the first parameter #table_name to make sure it uses only whitelist chars, and if not, write the attempt to a table in a different database (to both I have DML premissions).
If the name is good, it works fine, but if not, then python returns
TypeError: 'NoneType' object is not iterable
(which is expected and fine for me, as there is no such table), but it doesn't write to the table to which it was supposed to write, and the table gets stuck until I shut down the program.
When I run the stored procedure from SSMS with the same parameters, it works perfect, and writes successfully to the log table.
create_str = "CREATE PROC sp_General_GetAllData (#table_name AS NVARCHAR(MAX),\
#year AS INT, #month AS INT, #pd AS INT)
AS
BEGIN
SET NOCOUNT ON;
DECLARE #sql NVARCHAR(MAX) # for later uses
IF #table_name LIKE '%[^a-zA-Z0-9_]%'
BEGIN
# the 'log' table allows NULLs and the fields are used in other cases
INSERT INTO [myDB].[mySchema].[log]
VALUES (SUSER_SNAME(), NULL, NULL, NULL, NULL, NULL,
'INVALID TABLE NAME: ' + #table_name, GETDATE())
RAISERROR ('Bad table name! Contact your friendly DBA for details', 0, 0)
RETURN
END
# do some things if the #table_name is ok...
END"
cursor = sql_conn.execute(create_str)
cursor.commit()
# calling the SP from python - doesn't write to the log table which gets stuck
query = "{CALL sp_General_GetAllData (?, ?, ?, ?)}"
data = pd.read_sql(query, sql_conn, params=['just*testing', 2019, 7, 2])
# calling the SP from SSMS - works fine
EXEC sp_General_GetAllData 'just*testing', 2019, 7, 2
Because of the "*" inside the first parameter, it is expected to insert a line to [myDB].[mySchema].[log], which is happening only if I call the SP from SSMS, but not from python. Why?
SOLUTION:
With some luck I found out that the problem was that when the call to the SP was sent from python, the INSERT INTO clause was just not committed and it just waited for the commit order. The solution was to add auto_commit=True to the pyodbc.connect() function

I had the same issue, however, adding "auto_commit=True" to "pyodbc.connect()" didn't solve my problem. I solved it by adding the following command after the insert statement:
commit

Try this link.
Maybe your problem is from your configuration of mysql connection. By using SqlAlchemy, MySql connector or other connector, auto commit is disable by default.
About MySQLdb conn.autocommit(True), Mika's Answer

Error in Sqlite while Updating the table using Python

I am using a python to update entries in Sqlite table.
The command I am using is:
handle.execute("UPDATE RECORD set NAME=%s DEVICE=%s PROJECT=%s IP=%s COMMENT=%s where ID = %s"%(arg[2],arg[3],arg[4],arg[5],arg[6],arg[1]))
To this I get am getting an error as:
sqlite3.OperationalError: near "DEVICE": syntax error
I cannot understand what is specifically wrong with Device. Also I have checked the variables are as expected. The data base has a column named device and the database can be opened / accessed and edited using this python file.

There are commas missing between set items.
In addition to that, instead of string formatting, pass parameters to prevent SQL injection:
handle.execute(
"""UPDATE RECORD
SET NAME=%s, DEVICE=%s, PROJECT=%s, IP=%s, COMMENT=%s
WHERE ID = %s""",
(arg[2], arg[3], arg[4], arg[5], arg[6], arg[1]))
UPDATE
If you insist to use string formatting, you should quote %s: '%s'

Redshift query executed through python gives no records

I've written the following query to be executed through Python.
query="""SELECT DISTINCT count(*) FROM PG_TABLE_DEF WHERE schemaname='master' AND tablename LIKE '%%tmp%%'; """
#print(query)
conn=func_redshiftconnection()
res=conn.execute(sqlalchemy.text(query))
res=res.fetchall()
print(res) # Prints (0,)
It works fine in the database but is giving me 0 results when I execute it through Python and SqlAlchemy with psycopg2.
Idon't understand what the problem could be. Thanks for reading

PG_TABLE_DEF in Redshift only returns information about tables that are visible to the user, in other words, it will only show you the tables which are in the schema(s) which are defined in variable search_path. If PG_TABLE_DEF does not return the expected results, verify that the search_path parameter is set correctly to include the relevant schema(s).
Source - PG_TABLE_DEF
Try this -
mydb=# set search_path="$user",master;
Then run your query -
mydb=# select tablename from pg_table_def where schemaname = 'master';
If I’ve made a bad assumption please comment and I’ll refocus my answer.

Issue with the web.py tutorial when using sqlite3

For the record, I have looked into this, but cannot seem to figure out what is wrong.
So I'm doing the tutorial on web.py, and I get to the database part (can do everything above it). I wanted to use sqlite3 for various reasons. Since I couldn't figure out where to type the
sqlite3 test.db
line, I look into the sqlite3 module, and create a database with that. The code for that is:
import sqlite3
conn = sqlite3.connect("test.db")
print("Opened database successfully");
conn.execute('''CREATE TABLE todo
(id serial primary key,
title text,
created timestamp default now(),
done boolean default 'f');''')
conn.execute("INSERT INTO todo (title) VALUES ('Learn web.py')");
but I get the error
done boolean default 'f');''')
sqlite3.OperationalError: near "(": syntax error
I've tried looking into this, but cannot figure out for the life of me what the issue is.
I haven't had luck with other databases (new to this, so not sure on the subtleties), I wasn't able to just make the sqlite database directly so it might be a python thing, but it matches the tester.py I made with the sqlite with python tutorial...
Thanks if anyone can help me!

The problem causing the error is that you can't use the MySQL now() function here. Try instead
created default current_timestamp
This works:
conn.execute('''CREATE TABLE todo
(id serial primary key,
title text,
created default current_timestamp,
done boolean default 'f');''')

You are using SQLite but are specifying data types from some other database engine. SQLite accepts only INT, TEXT, REAL, NUMERIC, and NONE. Boolean is most likely being mapped to one of the number types and therefore DEFAULT 'F' is not valid syntax (although I don't think it would be valid in any version of SQL that does support BOOLEAN as a datatype, since they general use INTEGER for the underlying storage).
Rewrite the CREATE TABLE statement with SQLite datatypes and allowable default values and your code should work fine.
More details on the (somewhat unusual) SQLite type system: http://www.sqlite.org/datatype3.html

OperationalError creating an index in sqlite

EDIT: TL;DR version
I typed this
CREATE INDEX IF NOT EXISTS IDX_FILE_SIZE table_name (file_size);
instead of this
CREATE INDEX IF NOT EXISTS IDX_FILE_SIZE ON table_name (file_size);
Don't do that.

Some silly questions:
Is it a concidence that the offending statement is missing the word ON?
CREATE INDEX IF NOT EXISTS IDX_FILE_FULLPATH_FILE_PARENT_DIR ON table_name (file_fullpath, file_parent_dir);
CREATE INDEX IF NOT EXISTS IDX_FILE_SIZE table_name (file_size); -- missing ON
CREATE INDEX IF NOT EXISTS IDX_TAG_TITLE ON table_name (tag_title);
Somewhere in all the verbiage in your question, did I see the phrase "syntax error"?
Did you try the simple step of running the SQL statements in the sqlite3 command interpreter and seeing which syntax error you were actually getting?
E.g.
SQLite version 3.6.14
Enter ".help" for instructions
Enter SQL statements terminated with a ";"
sqlite> create table foo (bar int, zot int);
sqlite> create index barx on foo(bar);
sqlite> create index zotx foo(zot);
SQL error: near "foo": syntax error
sqlite>
Have you considered perusing TFRRD (The Fantastic Rail-Road Diagram) in the docs?
You wrote: """when I run that command in the smaller script (verifyIndexSmaller), it gives no error. If I then try to run the larger script again, even though the index has been created by the smaller script, I still get the error""".
Have you considered the possibility that you didn't run that command in the smaller script, but actually ran another (fixed!) version of that command?
Do you now understand why S.Lott was trying to get you to cut the waffle and focus on the piece of SQL that was causing the error?