[EMAIL PROTECTED] wrote:
>
> George ([EMAIL PROTECTED]) reports a bug with a severity of 2
> The lower the number the more severe it is.
>
> Short Description
> VB DAO MoveFirst/MoveLast become invalid operation
>
> Long Description
> The VB program gets DAO RecordSet from a query to Postgresql
Is it safe to assume that this difference of 30 mins would be consistent even if our
implementation in used across different timezones ?
Moreover it was found that if we retrieve the resultset as a getString instead of a
getTimestamp, it returns correctly.
But the valueOf operator to convert
The following problem occur using the sum() function (see the attached
file for all the details and an example):
- if you use it on a portion of a table (example: table age) you get a
result that differ from the one you can get by hand (see the whole table
temp1 and do the sum by hand)
R Ravishankar <[EMAIL PROTECTED]> writes:
> Moreover it was found that if we retrieve the resultset as a getString instead of a
>getTimestamp, it returns correctly.
Oh? That suggests that the problem is in JDBC or the underlying JVM.
I'd suggest asking the pgsql-jdbc list about it.
'group by' must be your problem.
If you remove that clause from your second query, you should then get
the same result (77) sum'ing the temp table...
I hope, it helps...
Dima
Marco Kienzle wrote:
>The following problem occur using the sum() function (see the attached
>file for all the details
Michael Enke ([EMAIL PROTECTED]) reports a bug with a severity of 2
The lower the number the more severe it is.
Short Description
lower()/upper() bug on ->multibyte<- DB
Long Description
OS: Linux Kernel 2.4.4, PostgreSQL version 7.2.1
lower() and upper() doesn't work like expected for multibyte
Marco Kienzle <[EMAIL PROTECTED]> writes:
> herring=3D# select sum(agenum) from age where weightmeanage>0 and lengthcel=
> l=3D160;
> sum=20
> -
> 77
> (1 row)
> select INTO TABLE temp1 inst, year, month, lengthcell, sex, age, agenum, w=
> eightmeanage from age where weightmeanage>0 and l
