Hot answers tagged db2
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 ...
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. ...
If you are appropriately licensed (Advanced Workgroup or Advanced Enterprise edition -- or Performance Management Option, HT to @IanBjorhovde) you can use a DB2 Workload Manager threshold to accomplish something like that. First you create a service class for your procedure: CREATE SERVICE CLASS sc_report You then define a workload that will assign the ...
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 );
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 ...
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 think the DEFERRED setting only affects CREATE OR REPLACE statements. If you want simple CREATEs to behave in this manner, set AUTO_REVAL to DEFERRED_FORCE.
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: ...
db2 => select next value for schema_name.sequence_name from SYSIBM.SYSDUMMY1; did the trick
Only top voted, non community-wiki answers of a minimum length are eligible