Re: Access violation - probably not the fault of Postgres

Paul,
Some questions come to mind.
1) Do these errors appear to be coming from the PG server, the odbc
driver, VB or DAO?
2) When you manually create the data, what are you using?

3) Have you tried replacing the Recordset.AddNew() function with the
database object's .execute() function? What I am basicly asking is, is
it possible to change the load_xxx_to_db() subroutine to return a SQL
query string.

4) Could you turn on the CommLog option in the ODBC driver, and send
that log to the mailing list along with your current VB logs?

David

Paul Lambert wrote:
> Paul Lambert wrote:
>> David Gardner wrote:
>>> Could you post the code in question? How are you initializing your
>>> recordset object? Have you tried feeding the database object an
>>> insert statement via the execute() function?
>>>
>>>
>>
>
> A few more case examples to go with the previously posted code...
>
>
> Record does not exist in the database, the following is therefore trying
> to add it.
>

> I then manually added an empty record with the 5 primary key fields
> having the same value as
> what my program has been trying to add and then piped the data into my
> program to try
> again.

>
> Success!
>
> Would this be some sort of permissions problem?
>
> To make matters more interesting, my program was adding two records into
> another table, said table was empty, thus adding new records in both
> cases. The first one worked but the second one caused an access violation.
>
>

> The first example points to a possible permissions problem, can update
> but not add - but the second example counters that by being able to add
> one record but not another which would point to something in the data...
> both completely contradicting each other. :(
>
> I'm tearing my hair out here (which is not really a problem since I'm
> shaving it all off for charity on Friday) trying to get this thing
> working... it's got me completely boggled.
>
> I'm in the process of setting up a small test case to rule out or
> confirm the data as being the problem. But that will have to wait until
> tomorrow to finish so I'll let you know what I find then, but if anyone
> has any other thoughts between now and then, I'd love to hear them.
>
> Thanks,
> Paul.
>
> --
> Paul Lambert
> Database Administrator
> AutoLedgers
>
> ---------------------------(end of broadcast)---------------------------
> TIP 9: In versions below 8.0, the planner will ignore your desire to
> choose an index scan if your joining column's datatypes do not
> match
>