APL - Using AP227 with PostgreSQL

Author

Using AP227 with PostgreSQL

me@privacy.net

2005-10-26, 6:56 pm

I am attempting to set up AL227 to work with PostgreSQL via ODBC and am
having problems determining what it is expecting in the arguments used to
connect to the database. I have a datasource set up in ODBC via my ODBC
Administrator and I can use that from another ODBC tool, but I either get
errors or crashes when I attempt to do so with AP227 from APL2. Has
anyone accomplished this? What arguments did you use with the connect
command?

-- Dave
-----------------------------------------------------------
dhdurgee<at>verizon<dot>net
-----------------------------------------------------------

APL2 Help

2005-10-27, 6:56 pm

Dave,

If you have a datasource name set up you should be able to say just
CONNECT 'DSN=xxxxxx'
where xxxxxx is your datasource name. If that doesn't work, its tough
to figure it out as each product's ODBC driver has its own syntax.
There is an example of the DSN= syntax and an example using Microsoft
Access to do it directly in the APL2 "Using SQL" manual, but again each
product is different.

Nancy Wheeler
APL Products and Services

me@privacy.net wrote:
> I am attempting to set up AL227 to work with PostgreSQL via ODBC and am
> having problems determining what it is expecting in the arguments used to
> connect to the database. I have a datasource set up in ODBC via my ODBC
> Administrator and I can use that from another ODBC tool, but I either get
> errors or crashes when I attempt to do so with AP227 from APL2. Has
> anyone accomplished this? What arguments did you use with the connect
> command?
>
> -- Dave
> -----------------------------------------------------------
> dhdurgee<at>verizon<dot>net
> -----------------------------------------------------------

me@privacy.net

2005-10-27, 9:55 pm

In <1130439033.584827.9820@o13g2000cwo.googlegroups.com>, on 10/27/2005
at 11:50 AM, "APL2 Help" <apl2@vnet.ibm.com> said:

>If you have a datasource name set up you should be able to say just
> CONNECT 'DSN=xxxxxx'
>where xxxxxx is your datasource name. If that doesn't work, its tough
>to figure it out as each product's ODBC driver has its own syntax. There
>is an example of the DSN= syntax and an example using Microsoft Access to
>do it directly in the APL2 "Using SQL" manual, but again each product is
>different.

I tried that and things crashed. Here is the trace log:

>[18:41:54.71] Share Proc: 1001 (0) tid:1 Var: DAT
>[18:41:55.06] Share (Exit rc:0)
>[18:41:55.06] SetACV Proc: 1001 (0) tid:1 Value: b
>[18:41:55.06] SetACV (Exit rc:0)
>[18:41:55.06] Pre-Spec Proc: 1001 (0) tid:1 Var: DAT
>[18:41:55.07] Pre-Spec (Exit rc:0)
>[18:41:55.07] Specify Proc: 1001 (0) tid:1 Var: DAT
>[18:41:55.07] Posting processor 227 Event = Partner Spec
>[18:41:55.07] Specify (Exit rc:0)
>[18:41:55.07] Pre-Ref Proc: 1001 (0) tid:1 Var: DAT
>[18:41:55.07] Pre-Ref (Exit rc:-1)
>[18:41:55.08] SVevent (Exit rc = 0) Processor 227 (1001) tid:2 - Partner Spec
>[18:41:55.08] Pre-Ref Proc: 227 (1001) tid:2 Var: DAT
>[18:41:55.08] Pre-Ref (Exit rc:0)
>[18:41:55.08] Reference Proc: 227 (1001) tid:2 Var: DAT
>[18:41:55.08] Posting processor 1001 Event = Partner Ref
>[18:41:55.09] Reference (Exit rc:0)
>[18:41:55.09] State Proc: 1001 (0) tid:1
>[18:41:55.09] State (Exit rc:0)
>[18:41:57.55] Warning: Processor 227,1001,0 terminated: 32-bit exception
>[18:41:57.55] Signoff Proc: 227 Parent: 1001 PParent: 0
>[18:41:57.55] Posting processor 1001 Event = Partner Retracted
>[18:41:57.55] Implicit retract. Processor 227 Variable DAT
>[18:41:57.55] State Proc: 1001 (0) tid:1
>[18:41:57.56] State (Exit rc:0)
>[18:42:27.30] Retract Proc: 1001 (0) tid:1 Var: DAT
>[18:42:27.54] Retract (Exit rc:0)
>[18:42:27.54] Signoff Proc: 1,1001,0
>[18:42:27.55] Implicit retract. Processor 1 Variable APL2
>[18:42:27.55] Signoff (Exit rc:0)
>[18:42:27.56] Signoff Proc: 101,1001,0
>[18:42:27.56] Signoff (Exit rc:0)
>[18:42:27.57] Signoff Proc: 1001,0,0
>[18:42:27.57] Posting processor 120 Event = Shutdown
>[18:42:27.58] Signoff (Exit rc:0)
>[18:42:27.58] Signoff Proc: 120,1001,0
>[18:42:27.59] Signoff (Exit rc:0)

And here is the trap log for that crash:

>10-27-2005 18:41:57 SYS3175 PID 00c3 TID 0002 Slot 0117
>J:\OS2-APPS\APL2OS2\BIN\AP227.EXE
>c0000005
>146a1835
>P1=00000002 P2=00a8e444 P3=XXXXXXXX P4=XXXXXXXX
>EAX=00000000 EBX=00bc3380 ECX=ffff1fe8 EDX=00bc4cd0
>ESI=00000000 EDI=00000052
>DS=0053 DSACC=f0f3 DSLIM=ffffffff
>ES=0053 ESACC=f0f3 ESLIM=ffffffff
>FS=150b FSACC=00f3 FSLIM=00000030
>GS=0000 GSACC=**** GSLIM=********
>CS:EIP=005b:146a1835 CSACC=f0df CSLIM=ffffffff
>SS:ESP=0053:00a9c45c SSACC=f0f3 SSLIM=ffffffff
>EBP=00a9f718 FLG=00012206
>PSQLODBC.DLL 0001:00001835

Other than noting that the crash occurs in the PSQLODBC.DLL that is the
ODBC interface to PostgreSQL I have no idea what this tells me or who I
should be contacting to correct it or correct my arguments. As I noted in
my prior posts I have another SQL front end that works via the ODBC
interface, so I know it can be done. That front end has its own problems,
however, under certain edgy conditions as well and will crash in a
particularly nasty fashion.

-- Dave
-----------------------------------------------------------
dhdurgee<at>verizon<dot>net
-----------------------------------------------------------

me@privacy.net

2005-10-28, 6:55 pm

Sponsored Links