On 11.08.2011 23:33, Guillaume Lelarge wrote:
On Wed, 2011-08-10 at 01:50 +0200, Erwin Brandstetter wrote:
On 10.01.2011 04:50, Erwin Brandstetter wrote:
On 06.01.2011 12:23, Guillaume Lelarge wrote:
Le 28/12/2010 20:18, Erwin Brandstetter a écrit :
(...)
Testing v.1.12.1 (Dec 13 2010, rev: REL-1_12_2) on Windows XP Pro, SP3
To be sure, I downloaded the latest version and upgraded. But there
have
been no more changes in the meantime. Connection tool still does not
behave as expected. I have tried with a couple of different
databases an
users.
On a closer inspection only the field "Uername" fails. "Database" seems
to be filled correctly. So, something has definitely changed, but half
the fix does not seem to work as expected.
Steps to reproduce:
- Open query tool
- Select<new connetion> from the connection tool --> popup "Connect
to Server" appears, "Server", "Database", "User" are filled with
current
values.
- Pick a new server --> new values are filled in for database and
user.
"Database" behaves as expected: identical name as in current
connection if available on the new server.
"Username" fails, however. Although a user of the same name is
available, some other value is filled in. On the first try some
(seemingly random) username from the list of available users is picked.
On subsequent tries it is always the first one on the list.
I tried on 1.12.2+ and it just works. Are you sure you have the exact
same user? no odd spaces or invisible characters?
I tested once more with two different sets of databases. No odd or
invisible characters.
Among other: username: "postgres", database: "event"
In each set of databases I switched between two almost identical
database clusters, the destination being a copy of the source.
Results were as described above: the matching database is filled in
but the username is lost in translation.
Maybe someone else can run a test to add evidence? It's easy: all you
need is two databases of the same name (like postgres) which share a
user of the same name (like postgres) ...
The recent case of "pkAscending not initialized" made me think. This one
is just like the other: Guillaume cannot see the error I get on Windows
XP. Maybe another variable not initialized?
I looked into dlgSelectConnection to see if something like that could
happen. AFAICT, it doesn't.
Testing in pgAdmin 1.14.0 Beta 3 on Win XP Pro. pg 8.4.8 and 9.0.4. I
tried a couple of combinations on two completely different PCs.
The issue is still there. I get a random pick (but the same under
identical circumstances) in the field "Username" where I would expect
the same username as in the present connection, which is available at
the new "server".
Could you give me your list of databases, users, and roles? the SQL
definition would be great, but I don't need the whole databases' schema.
Only the definition of these. Maybe I could find something with that.
This may seem unimportant, but if you use the feature a lot, switching
back an forth between test and productive servers with many roles, it is
a nuisance.
I understand. Just need a way to trigger the bug.
Thanks for looking into it, Guillaume!
I will try to build a portable testcase. This has to wait a couple of days,
though.
Regards
Erwin
--
Sent via pgadmin-support mailing list (pgadmin-support@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgadmin-support
