| From: | Arnaud Lesauvage <thewild(at)freesurf(dot)fr> | 
|---|---|
| To: | Hiroshi Inoue <inoue(at)tpf(dot)co(dot)jp> | 
| Cc: | pgsql-odbc(at)postgresql(dot)org | 
| Subject: | Re: Access2000 & sequence as primary key in view : #DELETED | 
| Date: | 2006-10-12 07:48:50 | 
| Message-ID: | 452DF362.50307@freesurf.fr | 
| Views: | Whole Thread | Raw Message | Download mbox | Resend email | 
| Thread: | |
| Lists: | pgsql-odbc | 
Hiroshi Inoue a écrit :
> Arnaud Lesauvage wrote:
>> Hiroshi Inoue a écrit :
>>> Though I don't understand the problem wholly, the virtual column "index"
>>> doesn't seem appropriate for the identifier. How do you find the row
>>> using the "index" ?
>> 
>> In Access, "index" is fine as a field identifier. You just have to 
>> reference it between brackets : [index].
> 
> What I meant is, for example
> 
> 1. Issue the query "select * from my_view".
> 2. You may get some data whose "index" = 1, 2, 3, .....
> 3. Then issue the query "select * from my_view where index = 1"
> 4. The query would return no data.
This is absolutely true, but actually this field is not really meant 
to be used as a primary key. I need it because this view is the base 
table of a csv export (and I need a unique "index" field in this export).
I chose it as the primary key in access only because I had no other 
"correct" field (integer, unique), and I know that I need this kind of 
field for a linked table to work correctly in Access.
Now I think that this #DELETED probleme does come from the fact that 
the index changes whenever you query the view.
For the moment, I use the view's "real" primary key in Access and it 
works OK (it is a 2 columns primary key though, but on two integer 
columns).
| From | Date | Subject | |
|---|---|---|---|
| Next Message | ioguix | 2006-10-12 08:00:24 | Re: LATIN1/9 conversion.... | 
| Previous Message | Hiroshi Inoue | 2006-10-12 07:42:34 | Re: Access2000 & sequence as primary key in view : #DELETED |