Re: Can't edit tables with timestamps

> -----Original Message-----
> From: Thomas Sandford [mailto:thomas(at)paradisegreen(dot)co(dot)uk]
> Sent: 28 March 2002 12:11
> To: Dave Page
> Subject: Re: [pgadmin-support] Can't edit tables with timestamps
>
>
> [ ... problems editing tables containing timestamps ... ]
> > > Thought (which may have occured to you and/or be impractical, but
> > > I'll mention it anyway) - if the table contains a primary
> key (as in
> > > this case) could you build the update where clause from
> that alone?
> > > Would fix at least some (and quite likely
> > > most) instances of this type of problem.
> >
> > That should fix *all* problems such as this. In fact, all
> we need is a
> > Unique column. The problem is that the ISUNIQUE property of
> each field
> > object in the recordset is null at the moment. I'll look
> into it some
> more.
>
> The exceptions I was thinking of were:
>
> 1) Where the table doesn't have a primary key defined (or
> with your wider strategy any unique fields)

In my reply above I was making the assumption that it would, if not we'd
fall back to the current method.

> 2) where that primary key (/unique field) is itself a timestamp.

Yes, this would be a problem. It's a fairly unlikely scenario though I'd
have thought. I can't think of any application where this would be a good
idea offhand.

> It would appear (from viewing the individual columns of a table within
> pgadmin) that pgadmin _can_ detect which column(s) is(/are) a
> primary key for a table (and of course, in database terms,
> the "right" way to specify a record from a table is in terms
> of the primary key value for that record).

Yes, we can detect it, but the mechanism used by pgAdmin for viewing the
schema is totally seperate from the data recordset. What I need to do is not
rely on the Recordset object, but go and query pgSchema to find suitable
columns. This may slow down the first edit of a table significantly though,
if that part of the object hierarchy hasn't been built, or caches haven't
been populated yet. That's not normally a problem, but I'd have to figure
out the best place for the queries to be made to give the best illusion of
speed.

Regards, Dave.