HI I am getting this exception when I am calling any stored procedure from my J2EE app.
Exception while calling stored procedure :Bigger type length than Maximum
I am having Oracle 9.1.0.7, JDK1.4 and using ojdbc14.jar running on Weblogic 8.1
Please advise what could be the root cause ?
Below is the manifest of my ojdbc14.jar
Manifest-Version: 1.0
Implementation-Version: "Oracle JDBC Driver version - 10.1.0.2.0"
Specification-Title: "Oracle JDBC driver classes for use with JDK1.4"
Specification-Version: "Oracle JDBC Driver version - 10.1.0.2.0"
Implementation-Title: "ojdbc14.jar"
Created-By: 1.2.2 (Sun Microsystems Inc.)
Implementation-Time: "Wed Jan 21 00:48:12 2004"
Implementation-Vendor: "Oracle Corporation"
Specification-Vendor: "Oracle Corporation".
It's a driver bug. Your version is already 6 years old. Download the latest and greatest from here.
See this post for a possible workaround.
For possible causes, see this thread:
There are bugs in different versions
of the drivers and different versions
of the database; most of them are
fixed in later versions.
For example, bugs produce the "Bigger
type length than maximum" in Oracle
database 8.1.7.2 or 9.0.1.1 for
certain very specific operations using
DB links; upgrading to 8.1.7.3 or
8.1.7.4 or 9.0.1.2 resolves those problems.
For example, bugs produce the "Bigger
type length than maximum" in Oracle
database 10.1.0.2 and 10.1.0.3 for
certain very specific operations
involving NLS characters; upgrading to
10.1.0.4 pr 10.2.0.1 resolves those problems.
For example, the 8.1.6 classes12.zip
had such a bug on certain operation
with databases in a UNICODE character
set, that was fixed in the 8.1.7.4
driver.
If you have an Oracle support
contract, you can find out this
information on the Oracle support
site; metalink.oracle.com If not,
download the latest versions of the
drivers and pray...
i downloaded the latest driver and now much better - now that all the referenced locations are updated
Another option than you can consider is review your query parameters, specially setFetchSize, if its too high this error is returned.
java.sql.SQLException: Bigger type length than Maximum
There is a maximun size depending on the database in my case 64kb (Oracle) my highest value have to be 65535
Reference document:
https://docs.oracle.com/cd/E11882_01/java.112/e16548/resltset.htm#JJDBC28621
Related
I have installed Zeoslib 7.2.4 because of updating to Delphi 10.2 and after testing my projects the result of SELECT isn't expected. The previous version 7.1.4 Works fine.
The results after updating to 7.2.4:
Connection ClientCodePage is binary. If I change this to utf8 the results will look like this, The Address col is correct but Title is still corrupted:
The database and table collation is latin1_swedish_ci. I don't have a problem with version 7.1.4. One workaround for this problem is this:
TEncoding.Default.GetString(DBQuery.FieldByName('Title').AsBytes)
This is the expected result:
I get the following error on startup after I upgraded from GRAILS 3.3.2 to 3.3.9:
org.apache.tomcat.jdbc.pool.ConnectionPool : Unable to create initial connections of pool.
org.h2.jdbc.JdbcSQLException: Scale($"10") must not be bigger than precision({1});
({1}); SQL statement:
CREATE CACHED TABLE PUBLIC.GAME(
ID BIGINT DEFAULT (NEXT VALUE FOR PUBLIC.SYSTEM_SEQUENCE_6AFE1F30_C0FB_47AD_B2B5_FD6A519957AE) NOT NULL NULL_TO_DEFAULT SEQUENCE PUBLIC.SYSTEM_SEQUENCE_6AFE1F30_C0FB_47AD_B2B5_FD6A519957AE SELECTIVITY 100,
VERSION BIGINT NOT NULL SELECTIVITY 3,
...
FINALROI DOUBLE SELECTIVITY 76,
STATUS VARCHAR DEFAULT 'FINISHED' NOT NULL SELECTIVITY 1
) [90051-197]
This problem only occurs when using an existing H2 database (that contains a lot of data). I tested with setting **dbCreate: create ** and everything works fine then. I also did a comparison of the schema created and it was identical to the one in my actual DB.
I also tested that the break happens with GRAILS 3.3.5. I went though the content of the release and could find nothing that would cause this behavior.
Could someone point me in the right direction? Is there a problem with the data in my database (somehow invalid inserts has happened or something) or is this caused by something else.
EDIT
Has to do with the H2 upgrade to version 1.4.197. Easy workaround is do downgrade by setting the previous version in build.gradle
runtime "com.h2database:h2:1.4.196"
The problem was bad sql which was was not properly validated due to a bug in earlier H2 versions. For some reason the schema contained a statement, where scale > precision:
_TIME TIMESTAMP(23, 10)
Fixed it with a DB conversion.
This code:
FDConnection.Open; // Design time TFDConnection; default settings
TabelGrid.Close; // TDFTable connected to TFDConnection; default settings
TabelGrid.TableName := 'TT_ACT';
TabelGrid.Open;
TabelGrid.Edit;
TabelGrid.FieldByName('TT_NAME').AsString := TabelGrid.FieldByName('TT_NAME').AsString + '*';
TabelGrid.Post;
fails with
[FireDAC][Phys][IB]-312 Exact update affected [0] rows, while [1] was requested
when Firebird 2.5.7 is installed, not when Firebird 2.5.3 is installed.
Call stack:
Conditions:
The TFDConnection points to a local .GDB file, driverID IB or FB, default sysdba password, all default settings. TFDPhysIBDriverLink or TFDPhysFBDriverLink present.
Delphi Tokyo 10.2.3 Win32 code, Windows 7
Firebird installed with option to put gds32.dll in System32; no spurious Firebird DLLs lying around
Interbase not present on system
The table has 3 indices:
TT_I0_ACT TT_ACT_ID Primary
TT_I1_ACT TT_PARENT_ID
TT_I2_ACT TT_FROMDATE
I've fumbled with settings, especially changing the default UpdateOptions.UpdateModes from UpWhereKeyOnly to UpWhereChanged or UpWhereAll, but no results so far.
What can be going on; what else can I investigate?
We distribute Firebird 2.5.3 with our app, but I'm afraid it will fail when clients already have a later version (as we found out when one of our developers upgraded FB).
Additional research:
The query that I see in TFDPhysCommandAsyncExecute.Execute (FireDAC.Phys.pas) for both versions is (with the default UpWhereKey update mode):
UPDATE TT_ACT SET TT_NAME = :NEW_TT_NAME WHERE RDB$DB_KEY = :OLD_DB_KEY
(actually, all FCommand properties show identical in the inspector).
I've looked through the Firebird 2.5.x. release notes and saw only one in 2.5.6 that is somewhat related:
The number of affected rows was reported incorrectly for an update against a view created WITH CHECK OPTION
I'm not sure this applies because it's about views. Setting UpdateOptions.CountUpdatedOptions to false makes no difference.
There's nothing in the 2.5.8 fixes list that indicates that a relevant bug was introduced in versions 2.5.4-2.5.7.
I have traced the FireDAC code to the point where execution differs in 2.5.3 and 2.5.7 but that ends with an interface method that I cannot trace:
TFDTable.InternalPost
TFDDataSet.InternalPost
TFDAdaptedDataSet.DoProcessUpdateRequest(arUpdate
TFDCustomTableAdapter.Update
TFDCustomTableAdapter.UpdateAdapterCmds(const ACmds: array of TFDActionRequest);
ACmds contains (arUpdate, arFetchRow)
back to TFDCustomTableAdapter.Update
TFDDAptTableAdapter.Update
TFDDAptTableAdapter.ProcessUpdate
In the 'build command if required' part
oCmd.SQLText := 'UPDATE TT_ACT'#$A'SET TT_NAME = ?'#$A'WHERE RDB$DB_KEY = ?'
ProcessRequest
in TFDDAptTableAdapter.ProcessRequest
SetParamsFromRow(ACommand.Params, ARow);
AParams.Count=2: NEW_TT_NAME and OLD_DB_KEY. OLD_DB_KEY value is 0 in both cases
then
ACommand.Execute;
TFDPhysCommand.Execute
ExecuteTask
TFDPhysCommand.ExecuteTask
FExecutor.Run
TFDStanAsyncExecutor.Run;
TFDStanAsyncExecutor.ExecuteOperation
FOperationIntf.Execute;
TFDPhysCommandAsyncExecute.Execute
TFDPhysCommand.ExecuteBase
FExecutor.Launched; -> Interface, cannot trace
Process_SingleRow
Process_HandleSystemFailure
InternalExecute -> Interface, cannot trace
This last call returns with var parameter ACount to 1 for 2.5.3, and 0 for 2.5.7
The GetRowCounts function returns
FRowsUpdated,FRowsDeleted,FRowsSelected,FRowsInserted: 1 0 1 0 in 2.5.3
FRowsUpdated,FRowsDeleted,FRowsSelected,FRowsInserted: 0 0 0 0 in 2.5.7
I am pretty new to neo4j and facing the following issue. When executing the batch-import (Micheal Hunger - batch importer) command I get this error about the cache_type settings. It is recommending gcr settings, but these are only available in the enterprise edition.
Help is very appreciated, thanks.
System Info:
win7 32bit 4G RAM (3G usable), jre7, neo4j-community-1.8.2
Data: (very small test data)
nodes.csv (tab-separated) 13 nodes
rels.csv (tab-separated) 16 relations
Execution and Error:
C:\Daten\Studium\LV HU Berlin\SS 2013\Datamanagement and BI\Neuer Ordner>java -server -Xmx1G -jar target\batch-import-jar-with-dependencies.jar target\db nodes.csv rels.csv
Using Existing Configuration File
Exception in thread "main" java.lang.IllegalArgumentException: Bad value 'none' for setting 'cache_type': must
be one of [gcr]
at org.neo4j.helpers.Settings$DefaultSetting.apply(Settings.java:788)
at org.neo4j.helpers.Settings$DefaultSetting.apply(Settings.java:708)
at org.neo4j.graphdb.factory.GraphDatabaseSetting$SettingWrapper.apply(GraphDatabaseSetting.ja va:215)
at org.neo4j.graphdb.factory.GraphDatabaseSetting$SettingWrapper.apply(GraphDatabaseSetting.ja va:189)
at org.neo4j.kernel.configuration.ConfigurationValidator.validate(ConfigurationValidator.java: 50)
at org.neo4j.kernel.configuration.Config.applyChanges(Config.java:121)
at org.neo4j.kernel.configuration.Config.<init>(Config.java:89)
at org.neo4j.kernel.configuration.Config.<init>(Config.java:79)
at org.neo4j.unsafe.batchinsert.BatchInserterImpl.<init>(BatchInserterImpl.java:83)
at org.neo4j.unsafe.batchinsert.BatchInserterImpl.<init>(BatchInserterImpl.java:67)
at org.neo4j.unsafe.batchinsert.BatchInserters.inserter(BatchInserters.java:60)
at org.neo4j.batchimport.Importer.createBatchInserter(Importer.java:40)
at org.neo4j.batchimport.Importer.<init>(Importer.java:26)
at org.neo4j.batchimport.Importer.main(Importer.java:54)
Batch.properties:
dump_configuration=false
cache_type=none
use_memory_mapped_buffers=true
neostore.propertystore.db.index.keys.mapped_memory=5M
neostore.propertystore.db.index.mapped_memory=5M
neostore.nodestore.db.mapped_memory=200M
neostore.relationshipstore.db.mapped_memory=500M
neostore.propertystore.db.mapped_memory=200M
neostore.propertystore.db.strings.mapped_memory=200M
ran into the same problem as you and i changed the line in batch.properties
cache_type=none to cache_type=gcr and it worked. not sure about how the speed changes for this. Not sure why the other options none, soft, weak, strong are not working.
Maybe Michael can give an answer to this?
Got the answer from the neo4j documentations
http://docs.neo4j.org/chunked/stable/configuration-caches.html#_object_cache
I have the following error in the Firebird Database. version 2.5.2
invalid request BLR at offset 163
function F_ENCODEDATE is not defined
module name or entrypoint could not be found
Error while parsing procedure GETMONTHSBYYEAR's BLR
Until last week everything was functioning correctly. This UDF exists on the disk. How can I debug this problem? Anyone can help me to sort out this problem.
PS: What I did so far to fix:
Backup / restore - no result. (any structure problem is fixed in my opinion after a BK/Restore).
Comment all dependencies, drop UDF function, recreate again - no result.
Potential problems could be that he UDF dll is inaccessible for the server (eg due to permissions, or the UDF restriction config in firebird.conf), or you have installed a 64 bit version of Firebird and your UDF is 32 bit (or vice versa), so Firebird cannot load the DLL.