Here is how am getting table names for a schema using sql alchemy
from sqlalchemy import inspect
inspector = inspect(engine)
table_list = inspector.get_table_names(schema="PUBLIC")
this gives me table names in lower case but actually tables exist with capital case in database, so i want to get table names with same case in which they exist in database/schema
Note: using snowflake database
Whether or not SQLAlchemy does "case normalization" is left up to the dialect because normalization can be convenient for some databases and a nuisance for others.
For example, the mssql+pyodbc:// dialect does not force table names to lower case:
with engine.begin() as conn:
conn.exec_driver_sql("DROP TABLE IF EXISTS MY_TABLE")
conn.exec_driver_sql("CREATE TABLE MY_TABLE (id int primary key)")
insp = sa.inspect(engine)
print(insp.get_table_names())
# ['MY_TABLE', 'tbl_main', 'tbl_temp']
You will probably have to ask the developers of snowflake-sqlalchemy about this.
In snowflake database, I just checked by creating tables with different cases and what i noticed is that if we create table with small/upper case name like (test/TEST) then SqlAlchemy returns name with small case in get_table_name method but if we create table with name having mix cases like (TestAbc) then it returns exact case so i think we can simply convert table names with lower case to upper after getting it from sql alchmey metadata/inspect method
Related
This is my mssql UDT
create type ConditionUDT as Table
(
Name varchar(150),
PackageId int
);
This is my mssql Stored Procedure
create Procedure [dbo].[Condition_insert]
#terms_conditions ConditionUDT readonly
as
begin
insert into dbo.condition (name, p_id)
select [Name],[PackageId]
from #terms_conditions;
end
There is a workaround solution if you do not have any other choice but definitely migrate from sql server to mysql.
The closest structural predefined object that takes on many rows in mysql is an actual table. So you need 1 table per UDDT of sql server. Make sure you use a specific schema or naming conversion so you know those tables are UDDT emulations.
The idea is fill in the info, use them into the sp and then delete them. You need however to gurantee who reads what and that info are deleted after usage, consumed. So:
For any of those tables you need 2 columns, i suggest put them always first. That will be the key and the variable name. The key can be char(38) and use UUID() to get a unique identifier. It can also be int and use the connectionid() instead. Unique identifier is better however as ensures that nobody will ever use information not indented for him no matter what. The variable name will be the one used into the sql server parameter, just a string. This way:
You know what UDDT you use out of the table name.
You know the identity of your process through the key.
You know the 'variable' out of the name.
So, in your application code you:
Begin transaction.
Insert the data into the proper (UDDT emulator) tables using a key and the variable name(s)
Supply to the stored procedure the key and the variable name(s). You can use the same key for many table type parameters within the same sp call.
The stored procedure can now use that information as before from the UDDT variable using key and variable name as filters to query the proper UDDT emulated table.
Delete the data you insert
Commit
On catch, rollback.
For simplicity your sp can read the data into temp table and you do not need to change a line of code from the original sql server sp for this aspect.
Transaction into your app code will help you make sure your temporary variable data will either be deleted or never committed no matter what goes wrong.
As Larnu thought might be the case, MySQL doesn't support user defined types at all, let alone user defined table types.
You will have to make them all separate scalar parameters.
I'm learning MySQL and this is probably the most basic of the basic questions I could ask, but I want to make sure I understand the syntax.
I have a MySQL script that created three different databases. If I wanted to select all fields from a specific database's table, I would use
SELECT * from database1.table1
correct? Or would it just be
SELECT * from table1
and if I wanted to select only two fields from another table, would it be
SELECT field1, field2 from database1.table2
or again just the table name?
Both forms are actually fine. In SQL you can qualify names to specify explicitly where a db object is located. This is useful for instance if you have a table2 in 2 different schemas (which is the correct term instead of "database", btw).
As it has been mentioned you can set a default schema to avoid having to add a schema to a reference (like your table2) all the time. If there is no schema given then the default schema (set with the USE schema command) will be taken instead. You still can use an explicit schema (either what is set as default or any other) if you like. This will help when you want to access an object which is not in the default schema.
I successfuly migrate mysql to oracle. But the only problem is case sensitive on table name and fieldname.Some pages in web said go to tools and option in sql developer and tick the ansi but i cannot find it.
On oracle website forum said it part of migration .
Anybody had new version of sql developer and migrate from mysql ?
E.g
calendarColor become CALENDARCOLOR
I really don't see how this is a problem. Since Oracle's objects are case-insensitive by default, you can continue to query them using SELECT * FROM calendarColor.
If you need them to be case sensitive, use quotes, like:
CREATE TABLE "calendarColor" ( ... );
SELECT * FROM TABLE "calendarColor";
See also: Schema Object Names and Qualifiers
If the table was created using
CREATE TABLE calendarcolor ( calendarColorId NUMBER(10,0) NOT NULL );
then the table name is stored in uppercase internally. When you run a statement like this:
select * from "calendarColor"
then you are telling Oracle: The table name should be treated case-sensitive but as there is not table named calenderColor, only one named CALENDARCOLOR your statement fails.
The fix is very easy: remove the quotes and change the select to
select * from calendarColor
so the code I am working on has this statement executed by PHP (note:This is taken from the PostgreSQL log file so it doesn't include any PHP stuff):
CREATE temporary table IF NOT EXIST temp tablename(id int primary key,
shared int default 0) replace select 1, userid as id
from tablefoo where sharedid = 1337
I don't quite understand what's going on here exactly, I know what a temporary table is, and I can quite accurately guestimate what IF NOT EXIST does, but what is replace doing here? I know replace is like insert but it replaces stuff as well, but in this case, nothing is specified for it to replace with, so does it just replace something with nothing and why the Select 1, I know that pretty much just tells you if your table has rows or something, but what is the point of using it here?
After some research, I found that IF NOT EXIST and replace do not exist in PostgreSQL. Most online sources suggest that SQL functions be used to replace them.
Should I use an SQL function to emulate IF NOT EXIST? If so, what would I write (sorry, I am pretty new to SQL) or should I just use a PHP function.
What about replace?
Sorry for the trouble, thanks for your time, oh and if you guys aren't busy or anything, you could also tell me about how to emulate "ignore", my current solution involves arbitrarily removing it.
Many uses in MySQL for temporary tables can be replaced in PostgreSQL with common table expressions or ordinary subselects.
WITH someCTE AS (
SELECT
...
) SELECT/UPDATE/DELETE ... WHERE sometable.column = someCTE.another_column;
Look into CREATE TABLE documentation. Temporary tables are just as name suggests not permanent:
If specified, the table is created as a temporary table. Temporary
tables are automatically dropped at the end of a session, or
optionally at the end of the current transaction (see ON COMMIT
below). Existing permanent tables with the same name are not visible
to the current session while the temporary table exists, unless they
are referenced with schema-qualified names. Any indexes created on a
temporary table are automatically temporary as well.
In particular temp tables are stored in diffrent (non-public) schema, e.g.:
=> Create Temporary Table someTempTable (value integer);
CREATE TABLE
=> \dt someTempTable
List of relations
Schema | Name | Type | Owner
-----------+---------------+-------+----------
pg_temp_2 | sometemptable | table | postgres
(1 row)
PostgreSQL doesn't have IF NOT EXISTS like in MySQL's CREATE TABLE, so you can't use it. If you want to create some table you need to firstly drop existing one (if it exists). Fortunately you could use SQL command DROP TABLE IF EXISTS to handle this:
=> Drop Table If Exists someTempTable;
DROP TABLE
=> Drop Table If Exists someTempTable;
NOTICE: table "sometemptable" does not exist, skipping
DROP TABLE
In SQL Server 2008 I had remade the database structure similar to Access. I need to import a couple of related tables but I am worried that the foreign keys won't match with the autonumber fields from the related tables.
You have some options here:
If you export the table to SQL Server, all the data will make it through properly and then you can set your PKs and FKs
Create the Table structure with an IDENTITY column and use SET IDENTITY_INSERT to put in the values you want into the Identity column.
Without knowing more details about your table structures and locations, I can only tell you generic things like
You will have to match the keys up manually so that the PK-FK references remain the same.
If you need to match the old access ids to the new autogenerated ids in an existing table, this is something you needed to do at the time of moving the data from the orginal table unless you happened to store the access ids. Usually I do some type of a cross matching table with the old id and the new id as part of the import process. Then you use this table to match to the realted tables to update their ids. If you didn;t do this and the ids are differnt, you will have to find a way to match them to the orginal access table first before you can import the related tables. I hope your table has a natural key in that case.
If the tables are the same you could use the rather verbosely named “Microsoft SQL server Migration Assistant 2008 for Access”. This will allow you to bring over the data whilst keeping the same keys