Question
Is it possible to do? I need to create a synonym in a database
with DB_LOCALE=en_us.utf8, for table in another database
with DB_LOCALE=en_us.819, or vice versa.
The error I'm getting
-23197 Database locale information mismatch.
The locale information GL_CTYPE or GL_COLLATE in the system catalog of
the specified database does not match the locale information in the
specified environment variable DB_LOCALE. Check the value of
DB_LOCALE.
Related
I want to find the data source vendor oracle or sql or DB2 on a query subject definition.How to achieve the same?
You can use the lineage tool if the data sources are named properly. https://www.ibm.com/docs/en/cognos-analytics/11.1.0?topic=vlidi-cognos-analytics-lineage-tool
Alternatively you can create a calculation with a bogus function and examine the error stack. For example an expression of add_spare(current_date) causes the following error:
XQE-DAT-0001 Data source adapter error: com.ibm.db2.jcc.am.SqlSyntaxErrorException: No authorized routine named "ADD_SPARE" of type "FUNCTION" having compatible arguments was found.. SQLCODE=-440, SQLSTATE=42884, DRIVER=3.72.54
RSV-SRV-0042 Trace back:
Which tells you the data source is DB2
I am trying to get data from DB2 table on z/OS in my Node application, where some of the values are stored in Arabic (IBM-420). The result that I am getting in application is the following:
������� ���� ���������
I am using ibm_db version 2.7.4 to fetch data from DB2 and:
Windows 10 - 64 bit
Node version: 14.17.3
NPM version: 7.19.1
I have tried to display the result on the console and writing it on a txt file using fs through following:
fs.writeFile('data.txt', content, err => {
if (err) {
console.error(err)
return
}
})
Any suggestion to convert the text into a proper Arabic?
Resolved by creating the system environment variable DB2CODEPAGE and setting its value to 1208 , then restarting all components to pick up this new variable.
When converting / translating between codepages , the Db2 CLI component will need to know the application code page, along with the DB2 server database code page and convert/translate between them as necessary. This requires the relevant conversion tables to be already present in the Db2 client (in this case the CLIDRIVER).
The DB2CODEPAGE environment variable value 1208 on Microsoft Windows forces the CLI components of Db2 to use Unicode as the application code page. When that DB2CODEPAGE variable is not present then the Db2 CLI component will try to derive the code page from the Microsoft Windows Control Panel Regional Options - which may not be what you need. Other values of this variable are possible, refer to the documentation for details.
When you set DB2CODEPAGE=1208 you must ensure that all the Microsoft -Windows applications really do use unicode or UTF-8 when inserting/updating data in the Db2 tables.
Does MemSQL support user variables in the load data command, similar to MySQL (see MySQL load NULL values from CSV data for examples)? The MemSQL documentation (https://docs.memsql.com/docs/load-data) doesn't give a clue, and my attempts at using user variables have failed.
No, variables in LOAD DATA are not currently supported in general (as of MemSQL 5.5). This is a feature we are tracking for a future release.
We only support the following syntax to skip the contents of a column in the file using a dummy variable (briefly mentioned in the docs https://docs.memsql.com/docs/load-data):
load data infile 'foo.tsv' into table foo (bar, #, #, baz);
My scenario is I upload an excel and take a column [ColumnExcel] in excel which is of type DT_WSTR and compare lookup that with a DB2 field[ColumnDB2] which is of type CHAR(9). I convert the DT_WSTR into DT_STR type and do the lookup. I execute this package via C# code and works perfectly fine in my local machine but it doesn't work and gives an error
"input column [ColumnExcelConverted] and reference column named [ColumnDB2] have incompatible data types."
in production machine.
1) My system has BIDS 2008 but in production it does not have BIDS but has Execute package utility of SQL server 2008 R2.
2) Also the driver in my system is IBM DB2 ODBC driver 8.01 while in production it is IBM DB2 ODBC driver 9.01.
What could be the problem and solution. I am still unable to find the exact cause.
The issue is most likely your differing versions of your ODBC driver.
My workplace has a .net application supplied to us by a postal service, it connects to an oracle database running on the same machine and is responsible for registering, storing and printing shipping labels.
Seeing as the database host etc. is configurable we asked the company if the application could be used over the network (simply copying it over to another machine resulted in "literal does not match format string" errors), all we were told is "it isn't possible". Not wanting to take no for an answer I poked around the exe with reflector.
Together with Oracle's v$sqlarea view I pinpointed the errors to a few date comparison functions, but I have no idea why the application was working in the first place on the original machine.
The original application uses queries similar to
SELECT * FROM shipping WHERE date = '2011/03/28' --error
easily fixed with something like
SELECT * FROM shipping WHERE to_char(date, 'yyyy/mm/dd') = '2011/03/28'
Why does the original application work without throwing any errors? The incorrect query pops up in the v$sqlarea view when the application is used on the original host, if I copy the query and run it manually using anything else it throws the error, if I run the application on any other machine it throws the error too, is there some setting in Oracle that is modifying queries on the fly, but only for queries originating from the local machine, while storing the original query in v$sqlarea?
This sounds like a regional settings difference between the two client machines, since formatting of dates will be dependent on the culture used to convert the date to a string in .NET, and unless the application specifies a culture, it will use the settings of the current logged on user running the application. This is obviously a problem if the database engine is expecting them in a certain format. This problem is less likely to arise with parametrized queries, where the date parameters are passed separate from the query and as a date datatype instead of a string.
If you work with dates, you must avoid String.Format based query generation. Use parametrized selects and parameters to set those values.
OracleCommand cmd = new OracleCommand("SELECT * FROM shipping WHERE date = :dataParam", connection);
var param = cmd.Parameters.Add("date", OracleDbType.Date);
param.Value = DateTime.Now;
It worked, because the format was matching the datetime settings on the developer machine and on the target database.
In other words: the issue is connected to an incorrect date time format you are trying to provide.
This could be because of regional settings on the server. Please check that the new server is configured for the same Locale (EN-GB, EN-US, or whatever the original server is configured to use).