New answers tagged db2
You cannot use the CASE expression in DB2 this way. The result of a CASE expression cannot be a boolean value. Your WHERE clause might look something like this, if one were to blindly translate your code: WHERE COUNTRY_CD = '81930' AND LANG_CD = '02' AND ( ( PARM_ADTR_ID = 'ALL' AND (AS_ADTR_ID_P IS NULL OR AS_ADTR_ID_P LIKE '%') ) ...
In this query: select next value for schema_name.sequence_name; next value is creating problem because we can not make the spaces while writing a query. So other thing you can do is found the max of value and increase it by 1. Below find query for that: select max(value)+1 for schema_name.sequence_name; This would be helpful for you.
Solution of your problem- SELECT CMSTKY AS Customer, CMNAME AS BusinessName, SUM(WKSLD#) AS LYSales FROM GPCMP INNER JOIN GPCM1P ON GPCMP.CMSTKY = GPCM1P.C1STKY INNER JOIN GMP725WP ON GPCMP.CMSTKY = GMP725WP.WKSTKY WHERE WKTERR = '055' AND WKSLD# != 0 GROUP BY CMSTKY, CMNAME
Containers for tablespaces 4-6 seem seriously unbalanced, I guess the E: path was added recenty. One thing you could start with is rebalance them: alter tablespace STORE_TS rebalance etc. You cannot control maximum size of a storage path, only a tablespace maximum size (which is calculated across all paths). If tablespace growth is causing harm on C: you ...
A table is placed in the reorg pending mode if you alter its physical structure, such as add or drop a column or change the column data type or nullability. Some operations do not place the table in reorg pending, but reorganization is required for the changes to take effect, for example, changing the table COMPRESS attribute or the inline length of a LOB ...
I guess it's a locking issue. While such inserts take so long use admin view below. The column HLD_CURRENT_STMT_TEXT shows the blocker statement (what cause the insert took so long): db2 select * from SYSIBMADM.MON_LOCKWAITS
As for the view being valid after dropping a column: The view is defined as SELECT * so the view is still valid. Regarding the validity of the view after dropping the table just use field VALID from SYSCAT.VIEWS, see below. db2 => DROP TABLE DB2INST1.TEMP_T DB20000I The SQL command completed successfully. db2 => SELECT SUBSTR(VIEWNAME,1,32) AS ...
You need to select from something. Another option is: db2 => values next value for schema_name.sequence_name; As you noted you can also use SYSIBM.SYSDUMMY1 or create a virtual table: db2 => select next value for schema_name.sequence_name from ( values 1 );
db2 => select next value for schema_name.sequence_name from SYSIBM.SYSDUMMY1; did the trick
I feel your pain. I've worked with both SQL Server and DB2. I will admit that IMHO, the data extraction and importing tools are not as simple or straightforward to use in SQL Server as they are in DB2. If you wish to stick to the database tools, here is what I recommend: Create queries to extract your data. Use CONCAT to encase each field with a character ...
Disclaimer, the following solution where for a development box. Use with caution. For a production like scenario, open a PMR. It turned out that during a previous restore the file system got full and therefore not all files necessary got created. I cataloged the database: db2 catalog db XXXX DB20000I The CATALOG DATABASE command completed successfully. ...
Since this is easier to elaborate on in an answer than in a comment..... We tended to install our instances to /inst/<instance-name>. I leave the instance naming scheme up to you. If you make it too similar than technically you have introduced a security risk as the instance names are eaiser to guess. Then you could so something like the following: ...
The cause of this problem most likely is the primary key of the table in DB2. Access can not handle some data types as primary keys well. Notoriously bad for PKs are all floating point numeric types. They may be rounded differently on the server and in Access. If Access uses a floating point value to query a single record from the server, there will be no ...
Top 50 recent answers are included