Nicholas Allen wrote:
>Ok I thought of that but what happens if there is no primary key in the table?
>
Then tough luck - as you said yourself, since everything else can be
duplicated, the primary key is the only way to
tell for sure which exact row you are talking about.
>I can probably add primary keys to the table but I didn't design the tables
>and so I have little (but luckily some) say over what columns appear in them.
>What has actually happened is that we have a view on a table and the view
>doesn't return the primary key. I'll try and ask the database administrator
>to add the primary keys.
>
>Thanks for the help though I guess it is the only way to do it. I was just
>hoping there would be a way to do it without a promary key to prevent changes
>to our database views.
>
I think you are better off redesigning your interface - even if you do
modify the view, and use those suggestions I mentioned earlier,
it will be slow like hell, unless your table only contains a few hundred
rows, in which case it doesn't matter if you send the whole table to the
client every time,
Dima
>
>On Wednesday 12 Feb 2003 9:37 pm, Bruno Wolff III wrote:
>
>
>>On Wed, Feb 12, 2003 at 20:55:21 +0100,
>>
>> Nicholas Allen <nallen@freenet.co.uk> wrote:
>>
>>
>>>I thought of this but the problem is that there may be multiple rows with
>>>the same value for the column I am sorting on. Eg if sorting on a surname
>>>then there may be 100s of people with the same surname so generating a
>>>where clause that selects up to the exact person previously selected is
>>>very difficult.
>>>
>>>
>>Then you should sort on surname AND whatever you are using as the primary
>>key.
>>
>>---------------------------(end of broadcast)---------------------------
>>TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.or
>>
>g
>
>
