Tag Info

Hot answers tagged

3

You can get most of those messages, but unfortunately not all. See my question on Stackoverflow regarding that. In general those messages (e.g. messages from a PRINT statement) are returned as warnings on the Statement object by the JDBC driver. To retrieve them use Statement.getWarnings() in a loop: Statement stmt = ...; stmt.execute("some sql"); ...


2

There are several ways to rewrite the query and even more because both subqueries use the same base table. Not sure why the error is thrown and who is to blame, the JDBC drivers, the Foxpro or something else, so here are a few alternatives: (1) using one query for both searches: SELECT COALESCE(SUM(CASE WHEN t.btyp = 5 THEN t.netto ...


2

Your trigger is fired for each statement not for each row. In statement level triggers you can not access the new and old records. You need to change your create trigger to create a row-level trigger, rather than a statement level trigger: CREATE TRIGGER my_trigger AFTER INSERT ON table2 FOR EACH ROW -- this is the change EXECUTE PROCEDURE ...


2

The parentheses form a row-constructor, so your query returns a single column row literal, essentially an anonymous composite type. Compare: regress=> SELECT (1,2); row ------- (1,2) (1 row) regress=> SELECT 1, 2; ?column? | ?column? ----------+---------- 1 | 2 (1 row) You would've quickly realised this if you'd run the query ...


2

Consider a parent/child table such as client/order. You can't delete a client that has an order. Say client 123 has an order A123. Fred does a delete for that order but does not commit. Then "Jane" tries to delete client 123. Since Fred's statement can potentially rollback, the client can't be deleted because it isn't allowed to the leave the order ...


2

Delete is a DML command and stores the data in redo log till the delete operation is committed. This means that if data to be removed by delete is slightly large[even though search time is less] it will take longer time as it will move data to redo log. So may be the instance when your operation took longer large no. of rows were being deleted to many ...


1

You should be just fine extending wait_timeout Notice the maximum value for wait_timeout for MySQL 5.0, 5.1, 5.5, 5.6 Linux : 31536000 seconds (365 days, one year) Windows : 2147483 seconds (2^31 milliseconds, 24 days 20 hours 31 min 23 seconds) These maximums would not exist of mysqld could not handle them. Connection pooling only saves on overhead in ...


1

This could happen if: - Your table MYTABLE has a unique column UNIQCOL - This MYTABLE.UNIQCOL is referenced by some column in another table, say MYTABLE2.UNIQCOL_REF - This MYTABLE2.UNIQCOL_REF is not indexed. Adding a (non-unique) index to MYTABLE2.UNIQCOL_REF could then solve the problem. (You said all FKs in MYTABLE are indexed, but you didn't say ...



Only top voted, non community-wiki answers of a minimum length are eligible