1. Forum
  2. Usenet
  3. COMP.OS.OS2.PROGRAMMER.MI

  • VisproRexx odbc

    From per@raiko.no@21:1/5 to All on Thu Oct 22 06:06:01 2015
    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)
  • From per@raiko.no@21:1/5 to p...@raiko.no on Fri Nov 20 06:09:25 2015
    On Thursday, October 22, 2015 at 3:06:01 PM UTC+2, p...@raiko.no 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)
  • From per@raiko.no@21:1/5 to p...@raiko.no on Fri Nov 20 07:43:13 2015
    On Thursday, October 22, 2015 at 3:06:01 PM UTC+2, p...@raiko.no 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)
  • From A.D. Fundum@21:1/5 to All on Sat Nov 21 11:13:59 2015
    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)
  • From per@raiko.no@21:1/5 to A.D. Fundum on Sat Nov 21 11:01:31 2015
    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)
  • From A.D. Fundum@21:1/5 to All on Mon Nov 23 08:46:57 2015
    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)
  • From PJ@21:1/5 to All on Tue Nov 24 13:04:51 2015
    /**/;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)
  • From A.D. Fundum@21:1/5 to All on Wed Nov 25 19:04:03 2015
    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)
  • From PJ@21:1/5 to All on Wed Nov 25 11:12:28 2015
    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)
  • From A.D. Fundum@21:1/5 to All on Thu Dec 3 12:36:51 2015
    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)
  • From PJ@21:1/5 to A.D. Fundum on Thu Dec 3 06:45:35 2015
    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)
  • From A.D. Fundum@21:1/5 to All on Sat Dec 5 17:28:18 2015
    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)