By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
438,374 Members | 2,014 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 438,374 IT Pros & Developers. It's quick & easy.

Rows created by a stored proc prompt Access' dreaded "write conflict"

P: n/a
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 ma*******@postgresql.org

Nov 23 '05 #1
Share this Question
Share on Google+
10 Replies


P: n/a
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 ma*******@postgresql.org
---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to ma*******@postgresql.org)

Nov 23 '05 #2

P: n/a
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 ma*******@postgresql.org
---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to ma*******@postgresql.org)

Nov 23 '05 #3

P: n/a
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 ma*******@postgresql.org
---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to ma*******@postgresql.org)

---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster

Nov 23 '05 #4

P: n/a
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 ma*******@postgresql.org
---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to ma*******@postgresql.org)

---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster

Nov 23 '05 #5

P: n/a

--- Sim Zacks <si*@compulab.co.il> 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.
I hope that you do it on the list, so that the rest of
us can profit from your experience.

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
ma*******@postgresql.org
---------------------------(end of
broadcast)---------------------------
TIP 2: you can get off all lists at once with the
unregister command
(send "unregister YourEmailAddressHere" to
ma*******@postgresql.org)



__________________________________
Do you Yahoo!?
Check out the new Yahoo! Front Page.
www.yahoo.com

---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to ma*******@postgresql.org

Nov 23 '05 #6

P: n/a

--- Sim Zacks <si*@compulab.co.il> 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.
I hope that you do it on the list, so that the rest of
us can profit from your experience.

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
ma*******@postgresql.org
---------------------------(end of
broadcast)---------------------------
TIP 2: you can get off all lists at once with the
unregister command
(send "unregister YourEmailAddressHere" to
ma*******@postgresql.org)



__________________________________
Do you Yahoo!?
Check out the new Yahoo! Front Page.
www.yahoo.com

---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to ma*******@postgresql.org

Nov 23 '05 #7

P: n/a
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 ma*******@postgresql.org
---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to ma*******@postgresql.org)

---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster
---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://archives.postgresql.org

Nov 23 '05 #8

P: n/a
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 ma*******@postgresql.org
---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to ma*******@postgresql.org)

---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster
---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://archives.postgresql.org

Nov 23 '05 #9

P: n/a
Hi Sim,
Got it! Set the Row Versioning Box in Page 2 of the DSN to checked and
the problem no longer occurs. Many thanks for helping me along.

Cheers,

Eric

Sim Zacks wrote:
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 ma*******@postgresql.org
---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to ma*******@postgresql.org)


---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster
---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://archives.postgresql.org

---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings

Nov 23 '05 #10

P: n/a
Hi Sim,
Got it! Set the Row Versioning Box in Page 2 of the DSN to checked and
the problem no longer occurs. Many thanks for helping me along.

Cheers,

Eric

Sim Zacks wrote:
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 ma*******@postgresql.org
---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to ma*******@postgresql.org)


---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster
---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://archives.postgresql.org

---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings

Nov 23 '05 #11

This discussion thread is closed

Replies have been disabled for this discussion.