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

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 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
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 6: Have you searched our list archives?
>
>                http://archives.postgresql.org
>