Thread: Problems editing tables
Hi,<br /><br />I've been having trouble editing a couple of tables in pgAdmin 1.6.3. The same operation works fine in 1.4.1,so I assume it's some sort of bug...<br /><br />The only tables (as far as I can tell) that are affected are PostGIS'geometry_columns' tables. Before anyone asks, they do have OIDs. <br /><br />Is there a reason for this, and is itsomething I can fix?<br /><br />Cheers,<br />Roland.<br />
Roland Martin wrote: > Hi, > > I've been having trouble editing a couple of tables in pgAdmin 1.6.3. > The same operation works fine in 1.4.1, so I assume it's some sort of bug... > > The only tables (as far as I can tell) that are affected are PostGIS > 'geometry_columns' tables. Before anyone asks, they do have OIDs. > > Is there a reason for this, and is it something I can fix? No idea - your report is somewhat vague. Please define 'trouble', including a description of what exactly you are trying to do, what errors you see, and what procedure you can use to reproduce them. A test table and sample data would also be a big help. Regards, Dave.
Hi Dave,
Mmm, OK. Thanks for your helpful response.
Trouble, in this case, means that it can't be done. I do the following:
1. Locate any geometry_columns table
2. Right click -> View data (or view all rows in the submenu, or whatever)
3. I click in a field in the f_table_name column, and make changes
4. I press any of enter; tab; or the little save button at the top
5. I press the 'refresh' button at the top
On 1.4.1, this then displays the data as amended.
On 1.6.3, it reverts to the data as it originally appeared.
I can replicate this on any of my geometry_columns tables, so I assume it's common to all PostGIS setups; if you need me to export one of my tables you'll have to tell me what form you want them in, and how to get them to that state. The table definition looks like this:
CREATE TABLE geometry_columns
(
f_table_catalog character varying(256) NOT NULL,
f_table_schema character varying(256) NOT NULL,
f_table_name character varying(256) NOT NULL,
f_geometry_column character varying(256) NOT NULL,
coord_dimension integer NOT NULL,
srid integer NOT NULL,
"type" character varying(30) NOT NULL,
CONSTRAINT geometry_columns_pk PRIMARY KEY (f_table_catalog, f_table_schema, f_table_name, f_geometry_column)
)
WITH OIDS;
ALTER TABLE geometry_columns OWNER TO postgres;
... and I don't think it matters what data is in there, as the same thing happens when you try to add a new row.
Cheers,
Roland.
Mmm, OK. Thanks for your helpful response.
Trouble, in this case, means that it can't be done. I do the following:
1. Locate any geometry_columns table
2. Right click -> View data (or view all rows in the submenu, or whatever)
3. I click in a field in the f_table_name column, and make changes
4. I press any of enter; tab; or the little save button at the top
5. I press the 'refresh' button at the top
On 1.4.1, this then displays the data as amended.
On 1.6.3, it reverts to the data as it originally appeared.
I can replicate this on any of my geometry_columns tables, so I assume it's common to all PostGIS setups; if you need me to export one of my tables you'll have to tell me what form you want them in, and how to get them to that state. The table definition looks like this:
CREATE TABLE geometry_columns
(
f_table_catalog character varying(256) NOT NULL,
f_table_schema character varying(256) NOT NULL,
f_table_name character varying(256) NOT NULL,
f_geometry_column character varying(256) NOT NULL,
coord_dimension integer NOT NULL,
srid integer NOT NULL,
"type" character varying(30) NOT NULL,
CONSTRAINT geometry_columns_pk PRIMARY KEY (f_table_catalog, f_table_schema, f_table_name, f_geometry_column)
)
WITH OIDS;
ALTER TABLE geometry_columns OWNER TO postgres;
... and I don't think it matters what data is in there, as the same thing happens when you try to add a new row.
Cheers,
Roland.
On 04/06/07, Dave Page <dpage@postgresql.org> wrote:
Roland Martin wrote:
> Hi,
>
> I've been having trouble editing a couple of tables in pgAdmin 1.6.3.
> The same operation works fine in 1.4.1, so I assume it's some sort of bug...
>
> The only tables (as far as I can tell) that are affected are PostGIS
> 'geometry_columns' tables. Before anyone asks, they do have OIDs.
>
> Is there a reason for this, and is it something I can fix?
No idea - your report is somewhat vague. Please define 'trouble',
including a description of what exactly you are trying to do, what
errors you see, and what procedure you can use to reproduce them. A test
table and sample data would also be a big help.
Regards, Dave.
Hi,
I'm going to reinstall the earlier version, since it does actually work. If anyone is ever interested in fixing this bug, please get in touch.
Cheers,
Roland.
I'm going to reinstall the earlier version, since it does actually work. If anyone is ever interested in fixing this bug, please get in touch.
Cheers,
Roland.
On 04/06/07, Roland Martin <roland.w.martin@gmail.com> wrote:
Hi Dave,
Mmm, OK. Thanks for your helpful response.
Trouble, in this case, means that it can't be done. I do the following:
1. Locate any geometry_columns table
2. Right click -> View data (or view all rows in the submenu, or whatever)
3. I click in a field in the f_table_name column, and make changes
4. I press any of enter; tab; or the little save button at the top
5. I press the 'refresh' button at the top
On 1.4.1, this then displays the data as amended.
On 1.6.3, it reverts to the data as it originally appeared.
I can replicate this on any of my geometry_columns tables, so I assume it's common to all PostGIS setups; if you need me to export one of my tables you'll have to tell me what form you want them in, and how to get them to that state. The table definition looks like this:
CREATE TABLE geometry_columns
(
f_table_catalog character varying(256) NOT NULL,
f_table_schema character varying(256) NOT NULL,
f_table_name character varying(256) NOT NULL,
f_geometry_column character varying(256) NOT NULL,
coord_dimension integer NOT NULL,
srid integer NOT NULL,
"type" character varying(30) NOT NULL,
CONSTRAINT geometry_columns_pk PRIMARY KEY (f_table_catalog, f_table_schema, f_table_name, f_geometry_column)
)
WITH OIDS;
ALTER TABLE geometry_columns OWNER TO postgres;
... and I don't think it matters what data is in there, as the same thing happens when you try to add a new row.
Cheers,
Roland.On 04/06/07, Dave Page < dpage@postgresql.org> wrote:Roland Martin wrote:
> Hi,
>
> I've been having trouble editing a couple of tables in pgAdmin 1.6.3.
> The same operation works fine in 1.4.1, so I assume it's some sort of bug...
>
> The only tables (as far as I can tell) that are affected are PostGIS
> 'geometry_columns' tables. Before anyone asks, they do have OIDs.
>
> Is there a reason for this, and is it something I can fix?
No idea - your report is somewhat vague. Please define 'trouble',
including a description of what exactly you are trying to do, what
errors you see, and what procedure you can use to reproduce them. A test
table and sample data would also be a big help.
Regards, Dave.
Roland Martin wrote: > Hi, > > I'm going to reinstall the earlier version, since it does actually work. > If anyone is ever interested in fixing this bug, please get in touch. I fully intend to look at it, unfortunately sometimes I simply don't have time to turn around bug fixes immediately in free software. Regards, Dave.
Roland Martin wrote: > Hi Dave, > > Mmm, OK. Thanks for your helpful response. > > Trouble, in this case, means that it can't be done. I do the following: > 1. Locate any geometry_columns table > 2. Right click -> View data (or view all rows in the submenu, or whatever) > 3. I click in a field in the f_table_name column, and make changes > 4. I press any of enter; tab; or the little save button at the top > 5. I press the 'refresh' button at the top > > On 1.4.1, this then displays the data as amended. > On 1.6.3, it reverts to the data as it originally appeared. On the latest dev code it works as expected with junk data in the table you suggested. Can you please try the latest snapshot build from http://developer.pgadmin.org/snapshots/win32/pgadmin3-20070612.msi and see how it behaves on your data? If there is still a problem, please use the right-click menu option and run a backup on a table that I can test with. Regards, Dave