*** cytrinox_ has joined #ingres | 05:13 | |
*** cytrinox has quit IRC | 05:17 | |
*** cytrinox_ is now known as cytrinox | 05:17 | |
*** stliu has joined #ingres | 06:00 | |
*** Alex| has joined #ingres | 06:37 | |
*** ChanServ sets mode: +o Alex| | 06:37 | |
*** Alex| has quit IRC | 07:07 | |
*** Alex| has joined #ingres | 07:22 | |
*** ChanServ sets mode: +o Alex| | 07:22 | |
*** Dejan has joined #ingres | 09:33 | |
*** Dejan has quit IRC | 10:21 | |
*** stliu has quit IRC | 10:32 | |
Alex| | can anyone tell me when integer8 has been introduced? | 11:42 |
---|---|---|
grantc | Alex|: 9.2 i think - check iiapi.h | 11:45 |
Alex| | following problem - Ingres 10 has a table with an i8 column. Ingres 2.x connects via NET, inserts an i4 value - this works... but now, when I try to insert a 13-digit value via Ingres 10 terminal I get integer overflow... so the 2.x insert does alter the table in some way. I have to modify to reconstruct to get it working again | 11:47 |
Alex| | I wouldn't mind if the 2.x insert fails because of incompatibility... but "breaking" the table isn't very nice | 11:48 |
grantc | IIAPI_VERSION_4 got it so I guess that was r3/9.0/Ingres2006 | 11:50 |
grantc | there used to be a wiki page that told you what API versions were tied to which release | 11:50 |
grantc | i would have assumed that 2.x should fail | 11:51 |
Alex| | as I said, I'm ok with incompatible releases but in this case the table is broken, data is lost/altered because all int8 values in the column are changed to some bogus negative values | 11:51 |
Alex| | not only on the 2.x client side but in the actual table itself! | 11:52 |
grantc | a bug if ever I saw one | 11:53 |
Alex| | and a pretty nasty one... | 11:54 |
grantc | yup | 11:54 |
grantc | indeed - it's kind of scary some of the things they are doing with it :) | 11:58 |
Alex| | well, it's only data, right? ;) | 11:59 |
grantc | it's just as well there are not enough statistians to analize it allç | 12:00 |
grantc | how's your job going? | 12:01 |
Alex| | good, busy, stressful :) | 12:01 |
Alex| | traveling a lot lately | 12:02 |
grantc | anywhere nice? | 12:02 |
Alex| | currently mostly Germany, Austria, Switzerland | 12:02 |
Alex| | maybe Canada in the future.. started a new project yesterday | 12:03 |
*** stliu has joined #ingres | 12:28 | |
*** PaulM05 has joined #ingres | 13:58 | |
PaulM05 | hi Alex, saw your issue about 2.6 -> 10.0 and i8s | 13:59 |
PaulM05 | it looks like it's a corruption of the RDF, when I tried it the table was accessible again once I'd flushed it (trace point rd001) or restarted ingres | 14:00 |
PaulM05 | hth | 14:00 |
Alex| | is this a dbms server bug or a missing compatibility check in the NET server? | 14:02 |
Alex| | whereas even when it's a missing check, the fact that a table gets corrupted isn't very nice :( | 14:03 |
PaulM05 | strictly speaking the table's not getting corrupted, the server's description of what the columns look like in memory (RDF) is wrong | 14:04 |
Alex| | ah, so they 13-digit values that show up as negative int4s are ok when I restarted the server? Didn't try that in my test case | 14:05 |
PaulM05 | that's what happened when I tested it, also when I ran the trace point | 14:06 |
*** PaulM05 has quit IRC | 15:20 | |
*** Alex| has quit IRC | 16:01 | |
grantc | Help: Simple generator that generates fixed shop.Operation operations (not random) | 16:47 |
grantc | oops :D | 16:47 |
* grantc steps away from the keyboard | 16:48 | |
*** DarylM1 has joined #ingres | 17:14 | |
*** Alex| has joined #ingres | 17:29 | |
*** ChanServ sets mode: +o Alex| | 17:29 | |
*** stliu has quit IRC | 17:52 | |
*** Dejan has joined #ingres | 18:12 | |
*** Dejan has quit IRC | 18:22 | |
*** Alex| has quit IRC | 18:30 | |
*** stliu has joined #ingres | 19:02 | |
*** stliu has quit IRC | 20:17 | |
*** cytrinox_ has joined #ingres | 20:27 | |
*** cytrinox has quit IRC | 20:30 | |
*** cytrinox_ is now known as cytrinox | 20:30 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!