Re: Rows created by a stored proc prompt Access' dreaded "write conflict"
От | Sim Zacks |
---|---|
Тема | Re: Rows created by a stored proc prompt Access' dreaded "write conflict" |
Дата | |
Msg-id | 917014919.20041102164101@compulab.co.il обсуждение исходный текст |
Ответ на | Re: Rows created by a stored proc prompt Access' dreaded "write conflict" (Eric E <whalesuit@bonbon.net>) |
Ответы |
Re: Rows created by a stored proc prompt Access' dreaded "write conflict"
(Eric E <whalesuit@bonbon.net>)
|
Список | pgsql-general |
Maybe you need some ODBC settings reconfigured: Here's what I have, I read a couple of these settings on various lists and websites and others were the defaults. I would guess if you don't have row versioning checked, that is the problem. Also, if you change ODBC settings you have to delete(unlink) the table and relink it. Just going to Linked Table Manager and refreshing doesn't do it. Access stores the ODBC settings in each table and does not really refresh it. So anytime you change the ODBC settings you have to delete all tables and relink them before it will catch. I would recommend deleting one table and testing, if possible, and when you find a setting that works then redo all the tables. Also I'm using 8.0beta1, so that might also be a difference. I'm using psqlODBC Page 1: The only checks I have are Disable Genetic Optimizer, KSQO and Recognize Unique Indexes. Unknown Sizes is set to Maximum. Max Varchar and LongVarchar are 4094. Page 2: The ones I have checked are LF<>CR?LF conversion, Updateable Cursors and Row Versioning. (If you don't have row versioning, that might be the problem, I'm pretty sure it's not a default) I tested both True is -1 on and off and it didn't make a difference, now I have it off. Int8 is Default and I'm not showing OID. Protocol is 7.X,6.4+ Let us know how it goes. Thank You Sim Zacks IT Manager CompuLab 04-829-0145 - Office 04-832-5251 - Fax ________________________________________________________________________________ Hi Sim, Thanks for the advice. The problem persists when I close and reopen any of the objects, or even the database client. I suspect it has something to do with how Access determines the uniqueID of the row, but that's only because that seems to be the major issue with Access and ODBC. Any other suggestions? Thanks, Eric Sim Zacks wrote: > After the stored procedure is run, call requery on the form that was > updated. > > We are in the middle of moving Access implementations to PostGreSQL. > I'd be happy to trade war stories, if you'd like. > > Thank You > Sim Zacks > IT Manager > CompuLab > 04-829-0145 - Office > 04-832-5251 - Fax > > ________________________________________________________________________________ > > Hi all, > I am using an Access client linked to a PG 7.4 server via ODBC. > > I have a stored proc on the server that inserts rows into a > table.particular table, accomplished via an INSERT > within the body of the stored proc. The procedure does not explicitly > commit this data, as no transactions are invoked. > > The problem is that Access will not modify these records via table or > form view, giving its generic "Write conflict: another user has modified > this record" message. It does just fine for any other records in the > table, but it will not modify those created by the stored proc. It will > also execute an UPDATE OR DELETE query to modify these records This > stored procedure is pretty key for us to go forward. > > Does anyone have any ideas of what's going on and how to fix it? I can > post more details, but I wanted to see if this was a known problem > before doing so. > > Many thanks, > > Eric > > ---------------------------(end of broadcast)--------------------------- > TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org > > > ---------------------------(end of broadcast)--------------------------- > TIP 2: you can get off all lists at once with the unregister command > (send "unregister YourEmailAddressHere" to majordomo@postgresql.org) > ---------------------------(end of broadcast)--------------------------- TIP 4: Don't 'kill -9' the postmaster
В списке pgsql-general по дате отправления:
Предыдущее
От: Jeff EckermannДата:
Сообщение: Re: Rows created by a stored proc prompt Access' dreaded "write conflict"