Обсуждение: PSQLODBC error
----------------------------------------------------------- An update here Byron, If I remove fields cl9 thru the end, the problem goes away. Try to add one more field back & it blows. The table as shown here is no trouble in psql or libpq. ----------------------------------------------------------- Hello Byron, I'm getting the following error when opening a particular PostgreSQL table. Access violation at adress 10001EF6 in module 'PSQLODBC'. Read of address FFFFFFFF. This does not happen with any other table. I have dropped and re-created, but no help. I've attached sql1.log. Following is the schema. PostgreSQL 6.4, psqlodbc 6.40.0004. Any clues? Thanks, Ken Table = tk_cfg +----------------------------------+----------------------------------+----- --+ | Field | Type | Length| +----------------------------------+----------------------------------+----- --+ | config_id | varchar() | 16 | | tkpath | varchar() | 0 | | netpath | varchar() | 0 | | workpath | varchar() | 0 | | temppath | varchar() | 0 | | execpath | varchar() | 0 | | applpath | varchar() | 0 | | statid | varchar() | 16 | | menudb | varchar() | 8 | | stepdb | varchar() | 8 | | procdb | varchar() | 8 | | typedb | varchar() | 8 | | cmnddb | varchar() | 8 | | conddb | varchar() | 8 | | pwdb | varchar() | 8 | | varfil | varchar() | 12 | | decprec | int2 | 2 | | touchcrt | char() | 1 | | refresh | int2 | 2 | | tempscript | varchar() | 8 | | appltemppath | varchar() | 0 | | applmenudb | varchar() | 8 | | applmenuid | varchar() | 25 | | applmenuexe | varchar() | 0 | | cl1 | int2 | 2 | | cl2 | int2 | 2 | | cl3 | int2 | 2 | | cl4 | int2 | 2 | | cl5 | int2 | 2 | | cl6 | int2 | 2 | | cl7 | int2 | 2 | | cl8 | int2 | 2 | | cl9 | int2 | 2 | | cl10 | int2 | 2 | | cl11 | int2 | 2 | | cl12 | int2 | 2 | | cl21 | int2 | 2 | | cl22 | int2 | 2 | | cl23 | int2 | 2 | | cl24 | int2 | 2 | | rptlen | int2 | 2 | | rptwid | int2 | 2 | | rptcmd | varchar() | 80 | +----------------------------------+----------------------------------+----- --+ pioneer=> \d tk_cfg_idx Table = tk_cfg_idx +----------------------------------+----------------------------------+----- --+ | Field | Type | Length| +----------------------------------+----------------------------------+----- --+ | config_id | varchar() | -4 | +----------------------------------+----------------------------------+----- --+
Вложения
Ken J. Wright wrote: > Byron, > > Some more info. In the driver setup, if Parse Statements is checked, the > error occurs. If not checked, then all is ok. I noticed in parse.c that > memory for field info is allocated in 32 field blocks. Perhaps the error is > here? At least I am now out of the deep water. > > Yeah, I had a feeling about the parse statements thing. I think you found a bug. FYI, the "parse statements" option was added before we had the 6.4 protocol. The newer protocol passes the size of the fields back in a query, which is something the old 6.3 protocol did not do. So I wrote this grand parse routine which would take a query and go ask the database about all the fields. The "parse statements" still has an advantage over the 6.4 protocol, in that it can find out about whether a field in a query can be "null" or not. Plus, it can find out about column alias names. Unfortunately, I don't think the parse statements can handle some of the newer syntaxes that will be introduced in 6.5. To be honest, I don't think the driver should be parsing sql statements too much anyway. Byron
subscribe end saludos Nico http://www.clubdelphi.com/nico