OSQL Incorrect syntax - Character Encoding - Powershell Scripting Help Needed - database

So we use osql to run in stored procedures as part of our build process. We use a project with an sp folder that gets published with applications as part of a build pack.
I used Visual Studio to create this project structure and created the sql scripts to run in the procs.
Visual Studio saved the files with UTF8 formatting (by default). osql when running in the scripts complained about every single script having a syntax error on line 1 i.e.
> Incorrect syntax near '´'. 1> 2> Msg 102, Level 15, State 1,
> Server GBEPIAP-SQL01, Line 1
Rather baffling.
Anyway; to fix the issue, the sql scripts could be saved with Unicode Codepage 1200 (File -> Advanced Save Options)
et voila - problem gone
Now that's left me with an even bigger problem; I have over 200 proc scripts that I need to open, change encoding and save with the new encoding.
Can any powershell guru do me up a quick script to change the encoding of every file in a folder to Unicode Codepage 1200? Would be doing me a favour while also saving time.

In the end I used the approach documented here
Save all files in Visual Studio project as UTF-8
But instead of UTF8; I specified Unicode.
foreach (var f in new DirectoryInfo(#"...").GetFiles("*.sql", SearchOption.AllDirectories)) {
string s = File.ReadAllText(f.FullName);
File.WriteAllText (f.FullName, s, Encoding.Unicode);
}

Related

Oracle database encoding and decoding

I'm running an SQL file with Shell script (.sh) contains an update statement but one of the columns is not inserted as needed, I tried to convert the file encoding to UTF-8 with notepad++ but the issue still in place.
bellow you will find the current value of the column and the correct version of it
current (issue):
R��servation
required:
Réservation
You must set the encoding of your shell according to NLS_LANG value.
On Windows it would be for example:
C:\>chcp 65001
Active code page: 65001
C:\>set NLS_LANG=.AL32UTF8
C:\>sqlplus ...
See also OdbcConnection returning Chinese Characters as "?"

Inputting a .sas7bdat file on SAS On Demand

I am using SAS Studio (the browser version) instead of a desktop SAS program.
I am trying to read a .sas7bdat file that I have uploaded onto a folder on SAS Studio.
libname HW5 '~/home/xxxxxxxxxxxx/sasuser.v94/HW5';
DATA FILE1;
set HW5.orders;
RUN;
I get the error:
ERROR: File HW5.ORDERS.DATA does not exist.
NOTE: The SAS System stopped processing this step because of errors.
WARNING: The data set WORK.FILE1 may be incomplete. When this step was stopped there
were 0 observations and 0 variables.
WARNING: Data set WORK.DISCOUNT_RET was not replaced because this step was stopped.
Here is the image of the folder:
https://ibb.co/hN83ua
I realize this is a simple error but I don't know how to fix it. Thanks! If nothing works, can i read this via infile?
Right click on the HW5 folder in the list on the left and select properties. This should show you the physical location for that folder. Copy it and paste it into your LIBNAME statement enclosed in quotes. Most likely the issue was your inclusion of the ~ in front of the path.
libname HW5 '/home/xxxxxxxxxxxx/sasuser.v94/HW5';

SQL Server Script Block number and block line

The error message when running my scripts includes:
Script block number: 9512; Block line 25;
What is a Script block number and how do I go to it in Visual Studio? (I'm using dbUp to create my database.
Thinking about Clay's comments, I went out to the source code for dbUp, which is over at the Git website. It turns out that the block line is the same as the sqlException.LineNumber. SqlException.LineNumber Property, according to MSDN, "Gets the line number within the Transact-SQL command batch or stored procedure that generated the error." So, now I have my answer!

PostgreSQL to MySQL data migration

I am trying to move my PostgreSQL database with all the data inside it to a MySQL database so I am using MySQL Workbench > Data migration tool.
On the "Reverse Engineer Source" step I got a strange error:
ERROR: Reverse engineer selected schemata: ProgrammingError("('42P01', '[42P01] ERROR: relation "public.psqlcfg_lid_seq" does not exist;\nError while executing the query (7) (SQLExecDirectW)')"): error calling Python module function DbPostgresqlRE.reverseEngineer Failed
The complete error log where this error message appears at its end is:
Starting...
Connect to source DBMS...
- Connecting...
Connecting to ...
Opening ODBC connection to DSN=InventoryDBDS...
Connected
Connect to source DBMS done
Reverse engineer selected schemata....
Reverse engineering public from InventoryDB
- Reverse engineering catalog information
Traceback (most recent call last):
File "C:\Program Files\MySQL\MySQL Workbench CE 6.0.6\modules\db_postgresql_re_grt.py", line 335, in reverseEngineer
return PostgresqlReverseEngineering.reverseEngineer(connection, catalog_name, schemata_list, context)
File "C:\Program Files\MySQL\MySQL Workbench CE 6.0.6\modules\db_generic_re_grt.py", line 228, in reverseEngineer
catalog = cls.reverseEngineerCatalog(connection, catalog_name)
File "C:\Program Files\MySQL\MySQL Workbench CE 6.0.6\modules\db_generic_re_grt.py", line 388, in reverseEngineerCatalog
cls.reverseEngineerSequences(connection, schema)
File "C:\Program Files\MySQL\MySQL Workbench CE 6.0.6\modules\db_postgresql_re_grt.py", line 76, in reverseEngineerSequences
min_value, max_value, start_value, increment_by, last_value, is_cycled, ncache = cls.execute_query(connection, seq_details_query % (schema.name, seq_name)).fetchone()
File "C:\Program Files\MySQL\MySQL Workbench CE 6.0.6\modules\db_generic_re_grt.py", line 76, in execute_query
return cls.get_connection(connection_object).cursor().execute(query, *args, **kwargs)
pyodbc.ProgrammingError: ('42P01', '[42P01] ERROR: relation "public.psqlcfg_lid_seq" does not exist;\nError while executing the query (7) (SQLExecDirectW)')
Traceback (most recent call last):
File "C:\Program Files\MySQL\MySQL Workbench CE 6.0.6\workbench\wizard_progress_page_widget.py", line 192, in thread_work
self.func()
File "C:\Program Files\MySQL\MySQL Workbench CE 6.0.6\modules\migration_schema_selection.py", line 160, in task_reveng
self.main.plan.migrationSource.reverseEngineer()
File "C:\Program Files\MySQL\MySQL Workbench CE 6.0.6\modules\migration.py", line 335, in reverseEngineer
self.state.sourceCatalog = self._rev_eng_module.reverseEngineer(self.connection, self.selectedCatalogName, self.selectedSchemataNames, self.state.applicationData) SystemError: ProgrammingError("('42P01', '[42P01] ERROR: relation "public.psqlcfg_lid_seq" does not exist;\nError while executing the query (7) (SQLExecDirectW)')"): error calling
Python module function DbPostgresqlRE.reverseEngineer
ERROR: Reverse engineer selected schemata: ProgrammingError("('42P01', '[42P01] ERROR: relation "public.psqlcfg_lid_seq" does not exist;\nError while executing the query (7) (SQLExecDirectW)')"): error calling Python module function DbPostgresqlRE.reverseEngineer Failed
I've searched the web for anything related to (error 42P01) appearing in the log, but couldn't find any reference. So if someone can please tell me what exactly I am doing wrong here that will be really great.
Thanks
This error bring me here.
If your "psqlcfg_lid_seq" actually including both uppercase and lowercase character(s), remember that PostgreSQL will convert the name into ALL lowercase for query.
A basic knowledge is: In order to perform a case matched query, the name must be wrapped by double quotation marks ("), so the convertion will be avoided.
However, in MySQL Workbench, they forget to do that when try to fetch sequences.
In db_postgresql_re_grt.py. Located in %Program Files%\MySQL\MySQL Workbench (Your version, for example "6.1 CE")\modules on Windows.
Line around 70, you will found the SQL query in the variable seq_details_query, it will be something like:
seq_details_query = """SELECT min_value, max_value, start_value,
increment_by, last_value, is_cycled, cache_value
FROM %s.%s"""
Change that to:
seq_details_query = """SELECT min_value, max_value, start_value,
increment_by, last_value, is_cycled, cache_value
FROM \"%s\".\"%s\""""
So the sequences can be fetched, and so whole flow can be proceed.
Notice that: You may need to restart MySQL Workbench to use modified scripts.
I'm surprised MySQL guys still not fix this problem. Maybe i need report the bug somehow? :P
42P01 is a generic error meaning the object doesn't exist.
In this case it's the sequence public.psqlcfg_lid_seq that does not exist.
Based on the series of error messages, the error happens when the tool tries to query the attributes of that sequence (with SELECT ... FROM schema_name.sequence_name)
Presumably this sequence is still referenced somewhere in the database even if ot no longer exists. In theory there are safeguards in PostgreSQL against this situation (dependency tracking) but I believe they depend on your server version and maybe on the specifics of the dependency.
To find the references to this sequence, one approach would be to dump the database schema to an SQL text file (with pg_dump -s) and search for the text psqlcfg_lid_seq within it.
Once found, presumably some ALTER statements may be able to remove the references.

Exporting UTF8 data from db2

I have a db2 table that contains values in many languages (including right-to-left languages.) When I export this table on a linux box using cli's ''export'' command, I get a good looking comma delimited text file (DEL file,) but when I try it on aix, it replaces all characters that are not in ascii with 0x1a.
I tried playing around with LC_LANG and DB2CODEPAGE, no go. I also tried using codepage modifier, but cli said it can't convert between these two codepages (any codepage I tried that is not English.)
I also tried IXF export, and the data is corrupted there as well.
Help! F1!
Thanks
The codepage of the database has to be set when creating the database. It is not possible to modify it later. You can check the codepage of the database with the following command and look for the value of "Database code page":
db2 get db cfg for [database_name]
Newer AIX versions shouldn't have problems with Unicode, but if you have and older version, that might cause problems too.

Resources