jdbcstatement.java

一个用java写的开源的数据库系统

        if (Trace.TRACE) {
            Trace.trace();
        }

        checkClosed();
    }

    /**
     * <!-- start generic documentation -->
     * Retrieves the maximum number of rows that a
     * <code>ResultSet</code> object produced by this
     * <code>Statement</code> object can contain.  If this limit is exceeded,
     * the excess rows are silently dropped. <p>
     * <!-- start generic documentation -->
     *
     * <!-- start release-specific documentation -->
     * <span class="ReleaseSpecificDocumentation">
     * </span>
     * <!-- end release-specific documentation -->
     *
     * @return the current maximum number of rows for a <code>ResultSet</code>
     *       object produced by this <code>Statement</code> object;
     *       zero means there is no limit
     * @exception SQLException if a database access error occurs
     * @see #setMaxRows
     */
    public int getMaxRows() throws SQLException {

        if (Trace.TRACE) {
            Trace.trace();
        }

        checkClosed();

        return iMaxRows;
    }

    /**
     * <!-- start generic documentation -->
     * Sets the limit for the maximum number of rows that any
     * <code>ResultSet</code> object can contain to the given number.
     * If the limit is exceeded, the excess
     * rows are silently dropped. <p>
     * <!-- end generic documentation -->
     *
     * <!-- start release-specific documentation -->
     * <span class="ReleaseSpecificDocumentation">
     * </span>
     * <!-- end release-specific documentation -->
     *
     * @param max the new max rows limit; zero means there is no limit
     * @exception SQLException if a database access error occurs
     *          or the condition max >= 0 is not satisfied
     * @see #getMaxRows
     */
    public void setMaxRows(int max) throws SQLException {

        if (Trace.TRACE) {
            Trace.trace();
        }

        checkClosed();

        iMaxRows = max;
    }

    /**
     * <!-- start generic documentation -->
     * Sets escape processing on or off.
     * If escape scanning is on (the default), the driver will do
     * escape substitution before sending the SQL statement to the database.
     *
     * Note: Since prepared statements have usually been parsed prior
     * to making this call, disabling escape processing for
     * <code>PreparedStatements</code> objects will have no effect. <p>
     * <!-- end generic documentation -->
     *
     * <!-- start release-specific documentation -->
     * <span class="ReleaseSpecificDocumentation">
     * <b>HSQLDB-Specific Information:</b> <p>
     *
     * Up to HSQLDB 1.6.1, disabling escape processing for
     * <code>PreparedStatements</code> objects <i>does</i> have an effect. <p>
     *
     * HSQLDB 1.7.0 follows the standard behaviour. <p>
     *
     * </span>
     * <!-- end release-specific documentation -->
     *
     * @param enable <code>true</code> to enable escape processing;
     *     <code>false</code> to disable it
     * @exception SQLException if a database access error occurs
     */
    public void setEscapeProcessing(boolean enable) throws SQLException {

        if (Trace.TRACE) {
            Trace.trace();
        }

        checkClosed();

        // fredt - this is a no-brainer - we just override this method in
        // jdbcPreparedStatement.java with no action performed
        //
        // FIXME:TODO ??? (not sure which category this best fits in)
        //
        // In our current implementation, setEscapeProcessing false for a
        // jdbcXXXStatement *does* actually disable escape processing for
        // prepared/callable statements.  However, the javadocs mention that
        // prepared/callable statements are usually parsed prior to making a
        // setEscapeProcessing call, so disabling escape processing for
        // prepared/callable statements will have no effect.
        //
        // The big question is:
        //
        // "Why would we want to perform nativeSQL over and over again on
        // prepared/callable statements (or even regular statements,
        // if it is redundant)?"
        //
        // This is not efficient and makes the standard comments
        // innacurate against our current implementation.  It would be pretty
        // simple to set up something to preprocess escape processing
        // for prepared/callable statements, as well as something to
        // normalize, escape-process, and cache regular statmements (although
        // normalizing and caching is probably better left completely on the
        // engine side, rather than here in client-side code).
        //
        // boucherb@users 20020425
        bEscapeProcessing = enable;
    }

    /**
     * <!-- start generic documentation -->
     * Retrieves the number of seconds the driver will
     * wait for a <code>Statement</code> object to execute. If the
     * limit is exceeded, a <code>SQLException</code> is thrown. <p>
     * <!-- end generic documentation -->
     *
     * <!-- start release-specific documentation -->
     * <span class="ReleaseSpecificDocumentation">
     * <b>HSQLDB-Specific Information:</B> <p>
     *
     * Up to and including 1.7.1, HSQLDB always returns zero, meaning there
     * is no limit. <p>
     *
     * </span>
     * <!-- end release-specific documentation -->
     *
     * @return the current query timeout limit in seconds; zero means there is
     *       no limit
     * @exception SQLException if a database access error occurs
     * @see #setQueryTimeout
     */
    public int getQueryTimeout() throws SQLException {

        if (Trace.TRACE) {
            Trace.trace();
        }

        checkClosed();

        return 0;
    }

    /**
     * <!-- start generic documentation -->
     * Sets the number of seconds the driver will wait for a
     * <code>Statement</code> object to execute to the given number of seconds.
     * If the limit is exceeded, an <code>SQLException</code> is thrown. <p>
     * <!-- end generic documentation -->
     *
     * <!-- start release-specific documentation -->
     * <span class="ReleaseSpecificDocumentation">
     * <b>HSQLDB-Specific Information:</b> <p>
     *
     * Calls to this method are simply ignored; up to and including 1.7.1,
     * HSQLDB waits an unlimited amount of time for statement execution
     * requests to return. <p>
     *
     * </span>
     * <!-- end release-specific documentation -->
     *
     * @param seconds the new query timeout limit in seconds; zero means
     *     there is no limit
     * @exception SQLException if a database access error occurs
     *         or the condition seconds >= 0 is not satisfied
     * @see #getQueryTimeout
     */
    public void setQueryTimeout(int seconds) throws SQLException {

        if (Trace.TRACE) {
            Trace.trace();
        }

        checkClosed();
    }

    /**
     * <!-- start generic documentation -->
     * Cancels this <code>Statement</code> object if both the DBMS and
     * driver support aborting an SQL statement.
     * This method can be used by one thread to cancel a statement that
     * is being executed by another thread. <p>
     * <!-- end generic documentation -->
     *
     * <!-- start release-specific documentation -->
     * <span class="ReleaseSpecificDocumentation">
     * <B>HSQLDB-Specific Information:</B> <p>
     *
     * Up to and including HSQLDB 1.7.0, aborting a SQL statement is
     * <i>not</i> supported, and calls to this method are simply ignored. <p>
     *
     * </span>
     * <!-- end release-specific documentation -->
     *
     * @exception SQLException if a database access error occurs
     */
    public void cancel() throws SQLException {

        if (Trace.TRACE) {
            Trace.trace();
        }

        checkClosed();
    }

    /**
     * <!-- start generic documentation -->
     * Retrieves the first warning reported by calls on this <code>Statement</code> object.
     * Subsequent <code>Statement</code> object warnings will be chained to this
     * <code>SQLWarning</code> object.
     *
     * <p>The warning chain is automatically cleared each time
     * a statement is (re)executed. This method may not be called on a closed
     * <code>Statement</code> object; doing so will cause an <code>SQLException</code>
     * to be thrown.
     *
     * <P><B>Note:</B> If you are processing a <code>ResultSet</code> object, any
     * warnings associated with reads on that <code>ResultSet</code> object
     * will be chained on it rather than on the <code>Statement</code>
     * object that produced it. <p>
     * <!-- end generic documentation -->
     *
     * <!-- start release-specific documentation -->
     * <span class="ReleaseSpecificDocumentation">
     * <b>HSQLDB-Specific Information:</b> <p>
     *
     * Up to and including 1.7.1, HSQLDB never produces warnings and
     * always returns null.<p>
     *
     * </span>
     * <!-- end release-specific documentation -->
     *
     * @return the first <code>SQLWarning</code> object or <code>null</code>
     *       if there are no warnings
     * @exception SQLException if a database access error occurs or this
     *          method is called on a closed statement
     */
    public SQLWarning getWarnings() throws SQLException {

        if (Trace.TRACE) {
            Trace.trace();
        }

        checkClosed();

        return null;
    }

    /**
     * <!-- start generic documentation -->
     * Clears all the warnings reported on this <code>Statement</code>
     * object. After a call to this method,
     * the method <code>getWarnings</code> will return
     * <code>null</code> until a new warning is reported for this
     * <code>Statement</code> object. <p>
     * <!-- end generic documentation -->
     *
     * <!-- start release-specific documentation -->
     * <span class="ReleaseSpecificDocumentation">
     * <B>HSQLDB-Specific Information:</B> <p>
     *
     * Up to and including HSQLDB 1.7.0, <CODE>SQLWarning</CODE> objects are
     * never produced, and calls to this method are simply ignored. <p>
     *
     * </span>
     * <!-- end release-specific documentation -->
     *
     * @exception SQLException if a database access error occurs
     */
    public void clearWarnings() throws SQLException {

        if (Trace.TRACE) {
            Trace.trace();
        }

        checkClosed();
    }

    /**
     * <!-- start generic documentation -->
     * Sets the SQL cursor name to the given <code>String</code>, which
     * will be used by subsequent <code>Statement</code> object
     * <code>execute</code> methods. This name can then be
     * used in SQL positioned update or delete statements to identify the
     * current row in the <code>ResultSet</code> object generated by this
     * statement.  If the database does not support positioned update/delete,
     * this method is a noop.  To insure that a cursor has the proper isolation
     * level to support updates, the cursor's <code>SELECT</code> statement
     * should have the form <code>SELECT FOR UPDATE</code>.  If
     * <code>FOR UPDATE</code> is not present, positioned updates may fail.
     *
     * <P><B>Note:</B> By definition, the execution of positioned updates and
     * deletes must be done by a different <code>Statement</code> object than
     * the one that generated the <code>ResultSet</code> object being used for
     * positioning. Also, cursor names must be unique within a connection. <p>
     * <!-- end generic documentation -->
     *
     * <!-- start release-specific documentation -->
     * <span class="ReleaseSpecificDocumentation">
     * <b>HSQLDB-Specific Information:</b> <p>
     *
     * Up to and including 1.7.1, HSQLDB does not support named cursors,
     * updateable results or table locking via
     * <code>SELECT FOR UPDATE</code>, so calls to this method are
     * simply ignored. <p>
     *
     * </span>
     * <!-- end release-specific documentation -->
     *
     * @param name the new cursor name, which must be unique within
     *           a connection
     * @exception SQLException if a database access error occurs
     */
    public void setCursorName(String name) throws SQLException {

        if (Trace.TRACE) {
            Trace.trace();
        }

        checkClosed();
    }