Hello!
Assuming I have postgresql-jdbc-7.0.3-2 installed from an RPM on Red Hat
6.2
Do I have to follow the steps in
http://jdbc.postgresql.org/docs/#install and start from sources ?
Thanks in advance.
--
Evelio MartÃnez
---(end of broadcast)--
On Thu, 3 May 2001, Barry Lind wrote:
> With regards to your specific problem, my guess is that you haven't
> created you database with the proper character set for the data you are
> storing in it. I am guessing you simply used the default SQL Acsii
> character set for your created database
Doesn't java has its own encryption package? You could use
that to encrypt and decrypt the password.
--
Travis Bauer | CS Grad Student | IU |www.cs.indiana.edu/~trbauer
---
Barry Lind <[EMAIL PROTECTED]> writes:
> With regards to your specific problem, my guess is that you haven't
> created you database with the proper character set for the data you are
> storing in it. I am guessing you simply used the default SQL Acsii
> character set for your created database
Tony Grant <[EMAIL PROTECTED]> writes:
> On 04 May 2001 10:29:50 -0400, Tom Lane wrote:
>> Does this happen with a non-multibyte-compiled database? If so, I'd
>> argue that's a serious bug in the JDBC code: it makes JDBC unusable
>> for non-ASCII 8-bit character sets, unless one puts up with the
On 04 May 2001 11:40:48 -0400, Tom Lane wrote:
> > I fought with this for a few days. The solution is to dump the database
> > and create a new database with the correct encoding.
>
> > MULTIBYTE is not neccesary I just set the type to LATIN1 and it works
> > fine.
>
> But a non-MULTIBYTE backe
On 04 May 2001 10:29:50 -0400, Tom Lane wrote:
> > With regards to your specific problem, my guess is that you haven't
> > created you database with the proper character set for the data you are
> > storing in it. I am guessing you simply used the default SQL Acsii
> > character set for your
On 04 May 2001 11:40:48 -0400, Tom Lane wrote:
>
> But a non-MULTIBYTE backend doesn't even have the concept of "setting
> the encoding" --- it will always just report SQL_ASCII.
What kind of error message does "createdb -E LATIN1" give on a non
MULTIBYTE backend?
Maybe there needs to be a no
Tony Grant <[EMAIL PROTECTED]> writes:
> What kind of error message does "createdb -E LATIN1" give on a non
> MULTIBYTE backend?
$ createdb -E LATIN1 foo
/home/postgres/testversion/bin/createdb[143]:
/home/postgres/testversion/bin/pg_encoding: not found.
createdb: "LATIN1" is not a valid encod
On Thu, May 03, 2001 at 11:48:34PM +0200, Rolf Schillinger wrote:
> Hi again,
> it`s now offical, I found a bug in JDBC driver in pgsql 7.1 ;)
:)
> I had the following problems:
> /usr/local/jakarta-ant-1.3/bin//ant -buildfile ../../../build.xml
...
> expected
> [javac] return ${major}
Tony Grant wrote:
> On 04 May 2001 11:40:48 -0400, Tom Lane wrote:
>
>> But a non-MULTIBYTE backend doesn't even have the concept of "setting
>> the encoding" --- it will always just report SQL_ASCII.
>
>
> What kind of error message does "createdb -E LATIN1" give on a non
> MULTIBYTE backen
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
> Date: Fri, 4 May 2001 19:26:48 +0200
> From: Marko Kreen <[EMAIL PROTECTED]>
> Has anybody had success compiling unpatched 7.1 JDBC driver
> with JDK1.3 and Ant 1.2/1.3? If not, could this patch be
> applied? Ant 1.4 betas seem to be ok.
Yes.
On Fri, May 04, 2001 at 09:16:38PM +0300, Ned Wolpert wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> > Date: Fri, 4 May 2001 19:26:48 +0200
> > From: Marko Kreen <[EMAIL PROTECTED]>
>
> > Has anybody had success compiling unpatched 7.1 JDBC driver
> > with JDK1.3 and Ant 1.2/1.3?
Marko Kreen writes:
> Has anybody had success compiling unpatched 7.1 JDBC driver
> with JDK1.3 and Ant 1.2/1.3?
Yes. I have
$ java -version
java version "1.3.0"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.0)
Java HotSpot(TM) Client VM (build 1.3.0, mixed mode)
(downloaded fro
On Fri, May 04, 2001 at 11:14:07PM +0300, Ned Wolpert wrote:
> > > Yes. I could compile 7.1 with ant 1.3 without a problem.
> >
> > And Sun's JDK 1.3?
> >
>
> Yes.
Fun. Back on square one. So: on some unknown cases Ant 1.2/1.3
with combination of JDK1.3 will have following problems:
* Ant
Tom,
I don't consider it a 'uselessly obstrucionist policy' for the client to
use the encoding the server says it is using :-) The jdbc code simply
issues a 'select getdatabaseencoding()' and uses the value the server
tells it to. I would place the blame more on the server for lying to
the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
> Date: Fri, 4 May 2001 20:56:04 +0200
> From: Marko Kreen <[EMAIL PROTECTED]>
> > Yes. I could compile 7.1 with ant 1.3 without a problem.
>
> And Sun's JDK 1.3?
>
Yes.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.4 (GNU/Linux)
Comment:
Barry Lind <[EMAIL PROTECTED]> writes:
> Now it is an easy change in the jdbc code to use LATIN1 when the server
> reports SQL_ASCII, but I really dislike hardcoding support that only
> works in english speaking countries and Western Europe.
What's wrong with that? It won't be any more broken
I can see that I'm probably not going to win this argument, but I'll
take one more try. :-)
The basic issue I have it that the server is providing an API to the
client to get the character encoding for the database and that API can
report incorrect information to the client.
If multibyte is
no u don't need to follow those steps.
but u still hav to set the classpath for the jdbc driver in this rpm.
- Original Message -
From: Evelio Martinez <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, May 04, 2001 1:13 PM
Subject: [JDBC] rpm jdbc installation
>
> Hello!
>
> Ass
20 matches
Mail list logo
