Driver JDBC 2.8 dont work in JUL2015SP1?
I use 2.8 for ETL (run work with decimal, 2.18 dont work), and 2.18
for dashboards access.
Att,
--
Luciano Sasso Vieira
Data Scientist & Solutions Architect
luciano(a)gsgroup.com.br <http://www.gsgroup.com.br> | tel: 17 3353-0833
| cel: 17 99706-9335
www.gsgroup.com.br <http://www.gsgroup.com.br>
---
Este email foi escaneado pelo Avast antivírus.
https://www.avast.com/antivirus
Serious error in data recording of type numeric. Using the jdbc driver 2.8,
recording both base OUT2014SP4 when JUL2015SP1, records normally.
But when using any jdbc driver above 2.8, the recording is wrong,
for example, the value 845 is recorded as 850.
Is it a bug?
Att,
--
Luciano Sasso Vieira
Data Scientist & Solutions Architect
luciano(a)gsgroup.com.br <http://www.gsgroup.com.br> | tel: 17 3353-0833
| cel: 17 99706-9335
www.gsgroup.com.br <http://www.gsgroup.com.br>
---
Este email foi escaneado pelo Avast antivírus.
https://www.avast.com/antivirus
Hi,
Iam use MonetDB JUL 2015-SPI, and driver JDBC 2.18, but error on load data,
in rooud value, exampla, value 854 in source, load 850 in target.
I am test with driver JDBC 2.1 and run word, value 845, load in target
with 845.
any idea !!!
--
Luciano Sasso Vieira
Data Scientist & Solutions Architect
luciano(a)gsgroup.com.br <http://www.gsgroup.com.br> | tel: 17 3353-0833
| cel: 17 99706-9335
www.gsgroup.com.br <http://www.gsgroup.com.br>
---
Este email foi escaneado pelo Avast antivírus.
https://www.avast.com/antivirus
Hi,
I am running a setup on MonetDB where in concurrent transactions take
place. Everything works very fine but for a few transactions getting
aborted due to SQLExceptions.
I have set *auto commit to false* for all these transactions. I am getting
frequent SQLExceptions with the message as
*java.sql.SQLException: COMMIT: failed*
But if I retry the same transaction, this works fine. Any idea on what
would be the reason for frequent commit fails?
When I set *auto commit to true* for the transactions, I get similarly
frequent Exceptions but the message becomes
*java.sql.SQLException: COMMIT: transaction is aborted because of
concurrency conflicts*
Is it like both the exception thrown be for the same cause?
Any help much appreciated.
Thanks in Advance.
Vijayakrishna.P.
Mobile : (+91) 9500402305.
Hello there
I reported what I believe to be a bug in the import routines towards the end of September:
https://www.monetdb.org/bugzilla/show_bug.cgi?id=3812#c0 <https://www.monetdb.org/bugzilla/show_bug.cgi?id=3812#c0>
Below is a summary of the issue I encountered, I wasn’t sure if the bug tracker is live/active so trying on this mailing list.
Of course, this may be expected behaviour (though I doubt it) in which case would be useful to know.
[reply <https://www.monetdb.org/bugzilla/process_bug.cgi#add_comment>] [−] <https://www.monetdb.org/bugzilla/process_bug.cgi#>Description <https://www.monetdb.org/bugzilla/show_bug.cgi?id=3812#c0>Andy Barlow <mailto:andy.barlow@datum360.com> 2015-09-25 15:19:43 CEST
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_1) AppleWebKit/601.2.4 (KHTML, like Gecko) Version/9.0.1 Safari/601.2.4
Build Identifier:
If your import file contains a number of character combinations, such as \560, \561, \700 and probably lots of others, the copy into fails with a message like:
Failed to import table line 5 field 1 'varchar(20)' expected in 'FIVE\700'
Reproducible: Always
Steps to Reproduce:
1. create table test (test varchar(20));
2. create a load file test.txt with the following:
ONE
TWO
THREE
FOUR
FIVE\700
3. copy into test from 'test.txt' using delimiters '\t','\n';
4. fails with message:
Failed to import table line 5 field 1 'varchar(20)' expected in 'FIVE\700'
Actual Results:
Failed to import table line 5 field 1 'varchar(20)' expected in 'FIVE\700'
Expected Results:
should import OK, the character combinations are valid
[reply <https://www.monetdb.org/bugzilla/process_bug.cgi#add_comment>] [−] <https://www.monetdb.org/bugzilla/process_bug.cgi#>Comment 1 <https://www.monetdb.org/bugzilla/show_bug.cgi?id=3812#c1>Andy Barlow <mailto:andy.barlow@datum360.com> 2015-09-25 16:04:00 CEST
it appears that the copy command is treating the input as octal.
If you convert the backslash \ into its octal equivalent, \134 then it “works”.
In some cases, such as \700 an error is thrown.
With an import file test.txt:
ONE\101
ONE\134101
When imported into table test (test varchar(20)), you get:
ONEA
ONE\101
So the copy command is converting octal to UTF-8,ASCII equivalen
Andy Barlow
t: +44 7830 302268
www.datum360.com <http://www.datum360.com/>
...delivering a measured approach to engineering information
Please be advised that this email may contain confidential information.
If you are not the intended recipient, please do not read, copy or re-transmit this email. If you have received this email in error, please notify us by email by replying to the sender or by telephone and delete this message and any attachments. Thank you in advance for your cooperation and assistance.
In addition, Datum360 disclaim that the content of this email constitutes an offer to enter into, or the acceptance of, any contract or agreement or any amendment thereto; provided that the foregoing disclaimer does not invalidate the binding effect of any digital or other electronic reproduction of a manual signature that is included in any attachment to this email.
Hello developers,
I found a bug when using BigDecimals in prepared statements with MonetDB¹s
JDBC driver.
If I have a column of type DECIMAL(15,2) and insert a big decimal with the
value 627000.00 through a PreparedStatement, it will turn out as 630000.00
in the DB, since the MonetDB JDBC driver currently mixes up "precision"
and "scale", and rounds 627000.00 to a precision of 2 ciphers.
I made a bugfix for it, and it can be seen here:
https://github.com/shaagerup/monet-jdbc/commit/
ebc5e654dc28e3b56d4c4b610d3d339e675d6c2c
I¹m sorry for not committing it directly to your repository, but since I
am not a Mercurial user, I hope someone else will use this information to
improve the official JDBC driver.
Best regards
Søren Haagerup
The MonetDB team at CWI/MonetDB BV is pleased to announce the
Jul2015-SP1 bugfix release of the MonetDB suite of programs.
More information about MonetDB can be found on our website at
<http://www.monetdb.org/>.
For details on this release, please see the release notes at
<http://www.monetdb.org/Downloads/ReleaseNotes>.
As usual, the download location is <http://dev.monetdb.org/downloads/>.
Jul 2015-SP1 bugfix release
Client Package
* In the SQL formatter of mclient (the default) we now properly align
East Asian wide characters.
Bug Fixes
* 3789: Query on large string table fails on HEAPextend
* 3794: table function sys.rejects() and view sys.rejects() are
listed are metadata objects but give an (incorrect) error when they
are queried
* 3797: COPY INTO with incorrect number columns
* 3798: SELECT query with INTERSECT causes assertion failure
* 3800: LIKE is broken for many patterns
* 3802: Disk space never freed: a logical ref is keeped on a deleted
BATs
* 3803: SQL query parser fails to parse valid SELECT query with a
CASE .. END in it. It fails with parser error: identifier 'x'
ambiguous
* 3804: `monetdb status` command crashes under certain conditions
* 3809: Inefficient plan is generated for queries with many (>= 24)
joined tables which take a long time or an HEAPalloc error. I get
Error: GDK reported error. HEAPalloc: Insufficie
* 3810: Fix statistics gathering
* 3811: NOT LIKE not working if the operand doesn't contains
wildcards.
* 3813: COPY INTO fails on perfectly clean CSV file
* 3814: Server crash when using bitwise NOT operation in SQL query
* 3816: Server crashes when trying to convert timestamp to str with
incorrect format
* 3818: Crash when performing UNION/GROUP BY over tables with
different columns
* 3819: order of tables in FROM-clause has negative impact on
generated plan (using crossproducts instead of joins)
* 3820: mclient accepts table with repeated constraint which causes
crash on insert
* 3821: Unexpected error when using a number instead of a boolean
* 3822: Yet another LIKE operator issue
* 3823: JDBC Connection to a schema - setSchema() error
* 3825: MonetDB not cleaning intermediate results which leads to
filling up disk space and ultimately server crash
* 3827: Certains comparisons between UUID produce a MAL error
* 3828: Schema corruption after several ALTER TABLE statements and
server restart
* 3829: Certains simple WHERE clause cause MonetDB to segfault
without explanation
* 3830: Coalesce typing inconsistencies
* 3833: NULL literals refused at many places
* 3834: Date comparison returns incorrect results
* 3839: msqldump generates incorrect syntax ON UPDATE (null)
Hi MonetDB Dev,
I can import the data in Jul2015, but the latest code fails to import(Win7 64Bit). It crashes in table.c (I used the old version (Jul2015) of this file, there is no crash). To reproduce the crash:
1. execute bi_create_table.sql to create the table,
2. change the path of bi_data.txt in bi_copy_from_file.sql.
3. execute bi_copy_from_file.sql to copy data from file.
4. if server doesn't crash immediately, run #3 more times.
Thanks
Cline
从网易163邮箱发来的云附件
bi_copy_from_file.sql (109.03K, 2015年11月16日 17:11 到期)
下载
bi_create_table.sql (1.14K, 2015年11月16日 17:11 到期)
下载
bi_data.txt (50M, 2015年11月16日 17:11 到期)
下载