Registered Member
|
Hi,
This is long after the events described, I describe a 'best remembered' scenario. Actually it was created by kexi, but i decided to add in two additional Boolean fields at some stage. Kexi does not allow this without destroying the data so i may have added the fields direct through postgresql. I remember extracting the data in delimited format, adding a couple of blank fields at the end, and putting the data back into the modified database. i honestly do not know whether I added the new fields in through kexi or through postgresql. With this all achieved connecting with kexi as the normal user gave me this warning notice. However, I found that I could connect as the superuser and all ran well. For all the sins of this, it has been the modus operandi for some years. Looking recently at the postgresql database using pgAdmin I was prompted to retry access via kexi using the proper username/password, but no luck. is there anyway to recitify this situation? I'd like to get back on the correct track. I was prompted to revisit this because I intended to use pgAdmin to change the default of one of the Boolean fields, and then thought better of it at that moment - not wanting to find myself handling another error message of some sort. If that would cause no conflict with kexi I'd like to do that. Ok, fools rush in where angels fear to tread, I know. Regards Ian. |
Moderator
|
Hi Ian,
It would be less time-consuming if you send me privately (or publicly if it's not problem) the table in question so I can analyze it. Also kexi__* tables will be needed. Since this is a postgresql, a compressed SQL dump would be OK. |
Registered Member
|
Jaroslaw,
just confirming that I did send you a dump as requested Ian |
Registered users: bancha, Bing [Bot], Evergrowing, Google [Bot], lockheed, mesutakcan, sandyvee, Sogou [Bot]