Re: [INTERFACES] Weird behavior of ODBC driver ...

Поиск
Список
Период
Сортировка
От Byron Nikolaidis
Тема Re: [INTERFACES] Weird behavior of ODBC driver ...
Дата
Msg-id 388B445B.761AEEFE@home.com
обсуждение исходный текст
Ответ на Weird behavior of ODBC driver ...  (hph@hphbbs.ruhr.de (H.P.Heidinger))
Список pgsql-interfaces

"H.P.Heidinger" wrote:
> 
> Hello community,
> 
> I ran into problems with a particular table (~340 rows/ ~20 coloums).
> 
> I access the table via ODBC from within MS-Access'97.
> The query always crashes if the table is accessed. Here the excerpt from
> the debug-log (originally it was a one-liner, that I broke to achieve a
> better overlook):
> 
> -------------------------- 8< snip, snap 8< --------------------------------
> Jan 23 17:55:16 hphs5 logger: query: SELECT "oid","code","Adresse_falsch",
> '#S_C_H#',                                              |
> '#S_C_H#',                                              |
> '#S_C_H#'<-- comma missing, astraid entry?              |
> '#S_C_H#',                                              |
> '#S_C_H#'<-- comma missing, astraid entry?              |  Count is 12 here
> '#S_C_H#',                                              |  2 commas missing
> '#S_C_H#'     , (some space here -- syntactically o.k.) |
> '#S_C_H#',                                              |
> '#S_C_H#',                                              |
> '#S_C_H#',                                              |
> '#S_C_H#',                                              |
> '#S_C_H#',                                              |
> "ibm_id","Anmerkung","Lieferant","CATIA","CATVDAFS","CATSTEP","R/3","CSI","Servi
> ce alt","Service neu","Firmen_ID","Titel_ID",'#S_C_H#','#S_C_H#',"CATIA_ID","Las
> tmailing_date","Lastmailing_action","Bearbeiter","Bearbeit_Datum","Auswahl"  FRO
> M "Kontakte"  WHERE
> "oid" = 19495 OR                                        |
> "oid" = 19496 OR                                        |
> "oid" = 19497 OR                                        |
> "oid" = 19498 OR                                        |
> "oid" = 19499 OR                                        | Count is 10 here
> "oid" = 19500 OR                                        |
> "oid" = 19501 OR                                        |
> "oid" = 19502 OR                                        |
> "oid" = 19503 OR                                        |
> "oid" = 19504                                           |
> Jan 23 17:55:16 hphs5 logger: ERROR:  parser: parse error at or near "'"
>                                                                      ^^^
>                                                         small wonder with
>                                                         the missing commas!
> 
> Jan 23 17:55:16 hphs5 logger: AbortCurrentTransaction
> -------------------------- 8< snip, snap 8< --------------------------------
> 
> What are these '#S_C_H#' thingies? They cannot come from the ODBC driver
> (at least `grep'ing thru the driver-code for "S_C_H" brought nothing up.)
> 
> Meanwhile I separated the database via a dump and restored in on another
> machine with a fresh PGSQL installation (6.5.3nl) from RPMs (instead of my
> own compile of 6.5.3 under RH-Linux 5.2) -- but the result is exactly the
> same :-(
> 
> On the WingDog-client (a Toshiba-Notebook) I use Win'95 (B.1111) with
> Access'97 of Office'97pro. The ODBC driver is 6.40.0007.
> 
> Any ideas?
> (I've been banging my head against that for the entire weekend and ran out
> of ideas now)
> 
> Best regards, Peter
> --
> #--------- H.P. Heidinger, Steeler Str. 121, 45138 Essen /Germany ----------#
> # Tel: +49-201: 8903091 (ISDN)  # 287802 (voice) # 287803 (analog data/FAX)
> # Mobil: +49-172-7462130
> # -------------------- MicroSoft Pollution Survivor -------------------------
> 
> ************

The '#S_C_H#' is a placeholder for large columns that will be queried in
a different manner.  I think the columns in question here are large
objects (OLE), or memo fields, yes?  This way, Access doesn't have to
incur the overhead of processing these fields on every query, only when
absolutely necessary, like if you actually click in the column in
question.

Why the commas are missing, I can't imagine.  Sounds like an odd bug in
Access.  

Can you reduce the columns to a smaller subset to see if it still
happens?  

Also, what are the types of these columns?

Byron


В списке pgsql-interfaces по дате отправления:

Предыдущее
От: hph@hphbbs.ruhr.de (H.P.Heidinger)
Дата:
Сообщение: Weird behavior of ODBC driver ...
Следующее
От: Compte utilisateur Sultan-advl
Дата:
Сообщение: Re: [INTERFACES] Re: ODBC drive strange behavior