Hi,

Has anyone tried to get VisproRexx to work with odbc/dBase files?

VX-Rexx connects to the dbf files and read them correctly while VisproRexx always reports some errors such as various "cannot load SQL......" and environment allocation error: -1

Suspect there is something wrong/missing in the setup of Vispro
since VX-Rexx works.

Any ideas?

PJ

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Thursday, October 22, 2015 at 3:06:01 PM UTC+2, [email protected] wrote:

Hi,

Has anyone tried to get VisproRexx to work with odbc/dBase files?

VX-Rexx connects to the dbf files and read them correctly while VisproRexx always reports some errors such as various "cannot load SQL......" and environment allocation error: -1

Suspect there is something wrong/missing in the setup of Vispro
since VX-Rexx works.

Any ideas?

PJ

FYI I'm using the Q+E odbc driver which according to VPR documentation also
was used to create the template sample "qedbf.dbd".

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Thursday, October 22, 2015 at 3:06:01 PM UTC+2, [email protected] wrote:

Hi,

Has anyone tried to get VisproRexx to work with odbc/dBase files?

VX-Rexx connects to the dbf files and read them correctly while VisproRexx always reports some errors such as various "cannot load SQL......" and environment allocation error: -1

Suspect there is something wrong/missing in the setup of Vispro
since VX-Rexx works.

Any ideas?

PJ

Did some more testing and the problem seems to be with a routine not found.

-----

Arg window

/* register the rexx functions */

rc = rxfuncadd( 'SQLDBS', 'VPODBCDR', 'SQLDBS' );
rc = rxfuncadd( 'SQLEXEC', 'VPODBCDR', 'SQLEXEC' );

/* View as details Container SEARCHCNR0 */
rc=VpSetItemStyle(window, 'SEARCHCNR0', 'DETAILS')

/* turn on the hour glass */
value=VpLoadPicture('SYSICON',3)
CALL VpWindow window, 'SETPOINTER', value

/* start the dbase and run the SQL*/

call sqldbs 'START USING DATABASE DSN=dbname';
/* check for SQL errors */
if (SQLCA.SQLCODE <> 0) then
CALL VpMessageBox window, 'Error Starting Database : 'SQLCA.SQLCODE, SQLCA.SQLMSG
/* turn off the hour glass */
value=VpLoadPicture('SYSICON',1)
CALL VpWindow window, 'SETPOINTER', value

-----
Running the above, all generated by VPR, results in:
REXX0043: Error 43 running Main-When Opened. Thread 8. Line17: Routine not found.
Line 17 is this one:

call sqldbs 'START USING DATABASE DSN=dbname';

(Makes no difference if I try wihtout the DSN and dbname.)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Has anyone tried to get VisproRexx to work with odbc/dBase files?

Any ideas?

Line17: Routine not found.

call sqldbs 'START USING DATABASE DSN=dbname';

I'm not using Vispro (yet) nor ODBC-facilitis, so your information
helps. Ideas:

1. Use the right lowercase and uppercase names (of external functions) everywhere. IOW: names of external functions, like your "sqldbs" can
be case-sensitive.

2. Your syntax is rc=RxFuncAdd(...), but you are doing nothing with
the rc. You may as well use CALL RxFuncAdd 'Foo','Bar','Foo'.

3. The number of arguments doesn't change your results indeed.
Apparently the function "sqldbs" cannot be found, so this function
cannot check the number of arguments and return an "invalid call to
routine".

HTH.


--

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Saturday, November 21, 2015 at 11:25:04 AM UTC+1, A.D. Fundum wrote:

I'm not using Vispro (yet) nor ODBC-facilitis, so your information
helps. Ideas:

1. Use the right lowercase and uppercase names (of external functions) everywhere. IOW: names of external functions, like your "sqldbs" can
be case-sensitive.

2. Your syntax is rc=RxFuncAdd(...), but you are doing nothing with
the rc. You may as well use CALL RxFuncAdd 'Foo','Bar','Foo'.

3. The number of arguments doesn't change your results indeed.
Apparently the function "sqldbs" cannot be found, so this function
cannot check the number of arguments and return an "invalid call to routine".

HTH.

--

All the code I listed is generated by VisPro itself, (by dragging a table from the database designer to an empty form). I have also compared this code to the supplied DB2 sample and except it registers
'SQLAR' instead of 'VPODBCDR' and call SQLDBS 'START DATABASE MANAGER' I see no differences. The DB2 sample form opens without any
error messages.
My form is eventually opened OK after displaying 9 "Cannot load SQLGetFunctions, SQLColumnPrivileges etc."
When finally opened and I click the search button the container and
the entry fields are populated correctly.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

FWIW: I've obtained a copy of a VPODBCDR.DLL, and as such the used
mixed-case function names are not wrong. According to EXEHDR the
exported function name is "SQLDBS", so it should be properly
registered by RxFuncAdd.

/**/;CALL RxFuncAdd 'SQLDBS','VPODBCDR','SQLDBS';foo=sqldbs('Bar')

With ORexx (i.e. not the combination of VisPro/REXX _and_ the system's
ORexx) this one-liner returns error REX40, so the function _is_ found
and it can be used.

Of course this presumes that everything is up-to-date and right,
without exhausted system resources, so e.g. SysSearchPath('LIBPATH','VPODBCDR.DLL') is always able to locate the
DLL. You could add such a check to your (generated or typed) code.

Please note that a returned error REX40 would be okay, because it
would imply that the original problem is solved. The routine _was_
found, but it detected some (no such database, wrong argument, wrong
number of arguments, too many connections, it's Monday, ...) fatal
error.


--

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

/**/;CALL RxFuncAdd 'SQLDBS','VPODBCDR','SQLDBS';foo=sqldbs('Bar')
results in nothing here.

FYI I also have a thread in comp.lang.rexx where I now posted the following:

I'm using classic rexx and this is part of the trace output:

252 *-* Arg window;
>>> "2147484508"
256 *-* rc = rxfuncadd('SQLDBS','VPODBCDR','SQLDBS');
>>> "1"
257 *-* rc = rxfuncadd('SQLEXEC','VPODBCDR','SQLEXE');
>>> "1"
261 *-* rc = VpSetItemStyle(window, 'SEARCHNO0', 'DETAILS');
>>> ""
264 *-* value = VpLoadPicture('SYSICON', 3);
>>> "459915136"
265 *-* Call VpWindow window, 'SETPOINTER', value;
>>> ""
269 *-* Call SQLDBS 'START USING DATABASE DSN=employee';

After this I get 9 "Cannot load...." messages
SQLGetFunctions
SQLColumnPrivileges
SQLDataSources
SQLForeignKeys
SQLParamOptions
SQLPrimaryKeys
SQLProcedureColumns
SQLProcedures
SQLTablePrivilieges

Clicking ok on each of them and the form eventually opens without any records, but at this point it gets populated if I click search button.

So at least it does connect to the database file. Would be intereseting to see what results you will get if you run the same files on your system.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

comp.lang.rexx: they are, rare exceptions excluded, using their own Windows-based interpreter (ooRexx), including the ::REQUIRES and their
selfish language derivate of ORexx. comp.lang.oorexx would be a better newsgroup, but instead they'll assume that ooRexx is the standard in comp.lang.rexx.

I'm using classic rexx

That's a safe choice, at least for now. In general often ORexx may be
better, but ORexx could also introduce new errors (related to checking
code first based on the ANSI standard, or e.g. due to running out of
shared memory). VisPro/REXX should work with your CRexx, albeit it may
require an older version of the OS.

Check your rcs, make sure that the DLL can be found in the LIBPATH,
and perhaps first make sure that you can RxFuncAdd and use any simple
version. RxFuncAdd individual functions first, to avoid the risk that
a generic Load-function doesn't load all functions. As such it's
possible to RxFuncAdd and use a VRODBCDR.DLL function. My error REX40
is returned by it, unlike your REX43-error. I can reproduce a
REX43-error by e.g. using a DLL name which doesn't exist at all.

SQLGetFunctions

What is "SQLGetFunctions"? Did you RxFuncAdd it, or is this an
internal error message?

SQLProcedures

EXEHDR:

12 1 00000c04 SQLPROCEDURES exported, shared data

I cannot RxFuncAdd and use a function called "SQLPRODECURES".
RxFuncAdd returns 1, and calling it adds a SYS3175-entry to
x:\POPUPLOG.OS2.

I'm not using VisPro/REXX (yet), I don't have your code, I'm not using
ODBC nor SQL, and I don't have your database. Hence the general
suggestions and remarks in comp.lang.rexx, like checking the rc.

Is it possible for you to share whatever (database, your code, steps
required to execute it) is needed to reproduce your error, excluding VisPro/REXX v3.1.1 itself?

It may be a bug, but REX43 suggests that it cannot find a function
which CRexx should be able to find and use. If there's a bug, then you
still should be able to reproduce my REX40 with an invalid number of
arguments.

And did you give my REX40 one-liner a try with CRexx? If so, then did
you give it a try with VisPro/REXX? If VisPro/REXX still can load
exyternal DLL functions, then it should be reproducable too.


--

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

I did try the one-liner, but it did not produce any results.

Please send me an e-mail and I'll be happy to provide necessary files.

(By entering Google groups through my Google account a valid e-mail address got displayed on my posts. Was not intentional, but I've not got any spam so far.)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Please send me an e-mail and I'll be happy to provide necessary

files.

Which version of VPR are you using?

It's not unlikely that your last ODBC 3-discovery is important, but
just reporting error messages doesn't help other people helping you.
People will, for example, assume that the fatal error "cannot
find/load" is produced by the interpreter.

But it's also possible that one succesfully (and checked!!!) function
produces the non-fatal warning, so a next phase still populates
tables.

Ignoring an overload of tracing, you could have added code to debug
the issue and to check for detectacle errors. To help people helping
you. The number of users of both VPR and ODBC will be limited. So
people will be answering in "general mode", including the assumption
that you are using their bleeding ooRexx-interpreter for Windows.

By the way, I'm not going to try if I can use an ODBC DLL of that
other Rexx interpreter.

my Google account a valid e-mail address got displayed on my posts.

That;'s just scratching the surface of Google sharing personal data,
without the user being fully aware of that...


--

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Thursday, December 3, 2015 at 12:42:15 PM UTC+1, A.D. Fundum wrote:

Which version of VPR are you using?

I'm using VPR 3.1

Have sent you some files.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

VisproRexx always reports some errors such as various
"cannot load SQL......" and environment allocation error: -1

Suspect there is something wrong/missing in the setup of
Vispro since VX-Rexx works.

FTR: the "Cannot load" errors are produced by the database IDE/GUI,
and it are possible fatal warnings instead of fatal errors. At least
one of the problems seems to be that ODBCDBF.DLL cannot load
ODBCCP.DLL (error 87, according to PM DLL),


--

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)