Announcement

Collapse
No announcement yet.

SQL Tools closing a file it didn't open??

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • SQL Tools closing a file it didn't open??

    Here is an odd thing... I open a my_file on line 1 of my program. Then I call SQL Tools. All is well. Right before ending the program I call SQL_Shutdown. In the last few lines of my program I print to my my_file and then close it. Been having a strange Error 52 - Bad file name or number. Is it possible SQL Tools is closing my_file too??

    Normally the call to FREEFILE gives my_file 1 as the file number.

    I could just close SQL Tools last...

  • #2
    The SQL_Shutdown function does execute a PowerBASIC CLOSE statement (with no filenumber) as final step. It has no effect if you use the SQL Tools DLL, but if you use the SLL the CLOSE will affect your open files, too.
    "Not my circus, not my monkeys."

    Comment


    • #3
      OK! Thanks! Yes it is the SLL.
      What is a PowerBASIC CLOSE?

      Comment


      • #4
        SQL Tools is written in PowerBASIC, and the shutdown function includes a CLOSE statement. Because of the way SLLs work, it's just like having a CLOSE in your main source code.
        Last edited by Eric Pearson; 20 May 2017, 01:13 AM.
        "Not my circus, not my monkeys."

        Comment


        • #5
          SQL Tools is written in PowerBASIC, and the shutdown function includes a CLOSE statement .
          Really!

          Minus Seven style points for that, as a CLOSE statement affects files the software did not open.

          MCM
          SJSP
          Michael Mattias
          Tal Systems Inc.
          Racine WI USA
          mmattias@talsystems.com
          http://www.talsystems.com

          Comment


          • #6
            This line from Help for CLOSE
            If no file number is specified, CLOSE closes all open files.
            supports what MCM said. Though I've used it with no filenum on programs with multiple files and/or TCP or COMM devices open, and never noticed an effect on other programs files or devices.

            So has the operation of CLOSE changed since earlier versions, and Help accurately documents operation. Or, has saving a couple words in Help made an error in Help?

            Anyone?

            Dale

            Comment


            • #7
              "CLOSE" by itself (No file number specified) has always been documented to close all files open in a program; and as far as I know, that's the way it has worked forever, including in PB for MS-DOS.

              But now that I think about it... contrary to the documentation, I would think 'CLOSE' (all by itself) works only in the module in which found, since I think the file numbers are kept by module, not by program (Maybe not?) (Nah.... It has to work 'by module' otherwise you could never code a FREEFILE, OPEN and CLOSE in a DLL! )

              I've never really noticed, since I have always used "CLOSE n [,n]..." specifying which file(s) I want closed, and I generally put my CLOSE in the same procedure as I put the OPEN, since I believe "matched sets" should be coded that way.
              Michael Mattias
              Tal Systems Inc.
              Racine WI USA
              mmattias@talsystems.com
              http://www.talsystems.com

              Comment


              • #8
                Same wording in PBWin 9, PBCC 5, PBWin 8 and PBCC 4. Went back up and reread post #2. In an SLL would put the CLOSE in the same module as that program, so would close all files and devices, but not in other other modules (DLLs) or other programs. Windows should go to BSOD if did.

                Mr Drake, if/when you release a new PB, you might consider adding "in the same module" to quoted line
                Dale

                Comment


                • #9
                  ((Back to sync again ))
                  Dale

                  Comment


                  • #10
                    Yep, the CLOSE-all thing is not ideal and has been discussed here before. Surprised you missed it MCM. I am of course crushed by the deduction in style points, but I'll have to live with that stain.

                    The issue does not affect the use of a SQL Tools DLL in any way. The SLL issue didn't come to light for a very long time (years) because the SQL_Shutdown function is intended to be called immediately before program termination and that's what most people do. From the SQL Tools Help File, item #4 under "Four Critial Steps for Every SQL Tools Program"...

                    In order to simplify the SQL_Authorize, SQL_Init and SQL_Shutdown process, we recommend that you use a very small "wrapper" main function, like this:

                    Code:
                    FUNCTION PBMAIN AS LONG
                        SQL_Authorize %MY_SQLT_AUTHCODE
                        SQL_Init
                        FUNCTION = MainProgram
                        SQL_Shutdown
                    END FUNCTION
                    
                    FUNCTION MainProgram AS LONG
                        'your code goes here
                    END FUNCTION


                    ...and confine your own code to the MainProgram function. That way, no matter what happens in your code (short of an Application Error or GPF) the SQL_Shutdown function is guaranteed to execute.
                    Using the function as recommended avoids the problem. I can provide a patch to anybody who needs it but so far (if memory serves) nobody has requested it because it's so easy to work around. Call SQL_Shutdown last.


                    "Not my circus, not my monkeys."

                    Comment


                    • #11
                      The issue does not affect the use of a SQL Tools DLL in any way. ... The SLL issue didn't come to light for a very long time (years)
                      Hmm, I have to wonder if that's because SqlTools was in its own module (*.dll) , CLOSE only closed files opened by that module? And because SLLs did not exist until (Win 10? Maybe 9?) no "close a disk file" issues were ever reported?

                      Darn, now I am curious and will have to create some test code. It could be CLOSE is misdocumented or buggy (and has been for many years) because "PB file numbers" are managed by module rather than by process.

                      Note I say "misdocumented OR buggy" when I should just say "buggy" because if my guess ("per module") is correct, we just don't know if it's the code, the doc or both which are in error!

                      Michael Mattias
                      Tal Systems Inc.
                      Racine WI USA
                      mmattias@talsystems.com
                      http://www.talsystems.com

                      Comment


                      • #12
                        PB file handles (as well as DDT and other handles) are not shared between object modules. A PowerBASIC CLOSE in a DLL has never affected open files in the calling EXE. When an SLL is used, it becomes part of the EXE, similar to using an #INCLUDE -- where you would expect a CLOSE to affect open files.
                        Last edited by Eric Pearson; 13 Jun 2017, 12:42 PM.
                        "Not my circus, not my monkeys."

                        Comment

                        Working...
                        X