_SQLite_Close problem

[dmob]

So I am trying to implement an archive system of sorts for my (SQLite) DB app. I wrote a function to attach a separate (archive) DB and

sync the columns with main DB. If archive DB file does not exist, create file with _SQLiteOpen then close the file (and thus connection) with SQLite_Close.

This works as intended, however, after the create operation, all subsequent _SQLite_* functions returned a "Library misuse error".

After a little digging I found the problem in the _SQLite_Close function: it clears the "last opened database" handle even when there still is a live

DB connection open. All other functions then "think" there is no DB connection active. I hacked two functions in the UDF for a quick fix:

In _SQLite_Close: Change

...

$__g_hDB_SQLite = 0
__SQLite_hDel($__g_ahDBs_SQLite, $hDB)
Return $iRval[0]

to:

$__g_hDB_SQLite = __SQLite_hDel($__g_ahDBs_SQLite, $hDB)
Return $iRval[0]

and in Func __SQLite_hDel changed

Func __SQLite_hDel(ByRef $ahLists, $hGeneric)
    Local $iElement = _ArraySearch($ahLists, $hGeneric)
    If $iElement > 0 Then _ArrayDelete($ahLists, $iElement)
EndFunc   ;==>__SQLite_hDel

to:

Func __SQLite_hDel(ByRef $ahLists, $hGeneric)
    Local $iElement = _ArraySearch($ahLists, $hGeneric)
    If $iElement > 0 Then
        _ArrayDelete($ahLists, $iElement)
        Return $ahLists[UBound($ahLists)-1] ; Return last opened db
    EndIf
    Return 0
EndFunc   ;==>__SQLite_hDel

so it preserves last opened DB again.

 

My archive function now works great

I'm not sure if this should be classified as a bug, but I believe so...

Hope this helps someone before

Edited June 16, 2020 by dmob
Add. info.

[TheDcoder]

@dmob Please create a ticket in the bug-tracker so that the devs can track this bug.

[dmob]

TheDcoder,

Do I have to re-explain the bug or can I just link to this topic?

[jchd]

Before creating a ticket, please post a short, stand-alone reproducer here, using the standard unmodified include.

[Melba23]

dmob,

Please do as jchd has suggested.

M23

[dmob]

23 minutes ago, jchd said:

Before creating a ticket, please post a short, stand-alone reproducer here, using the standard unmodified include.

expandcollapse popup

#include <SQLite.au3>
 _Example()

Func _Example()

    Local $sSQliteDll = _SQLite_Startup()
    ConsoleWrite("+ SQliteDll: " & $sSQliteDll & @CRLF)


    ; Create DB1
    Local $sFile1 = @ScriptDir & "\DB1.db"
    Local $oDB1 = _SQLite_Open($sFile1) ; create if not exist
    If @error Then
        ConsoleWrite("! OpenCreateErr[" & @error & "] " & _SQLite_ErrMsg() & @CRLF)
    Else
        ConsoleWrite("+ DB1 Handle: " & $oDB1 & @CRLF)
    EndIf

    ; Create DB2
    Local $sFile2 = @ScriptDir & "\DB2.db"
    Local $oDB2 = _SQLite_Open($sFile2) ; create if not exist
    If @error Then
        ConsoleWrite("!OpenCreateErr[" & @error & "] " & _SQLite_ErrMsg() & @CRLF)
    Else
        ConsoleWrite("+ DB2 Handle: " & $oDB2 & @CRLF)
    EndIf

    ; close DB2
    _SQLite_Close($oDB2)

    ; now attach DB2 to DB1
    Local $sQry = "ATTACH '" & $sFile2 & "' AS DB2;"
    Local $vRet = _SQLite_Exec(-1, $sQry)
    If @error Then
        ConsoleWrite("! AttachErr[" & @error & "] " & _SQLite_ErrMsg() & @CRLF)
    Else
        ConsoleWrite("+ ATTACH Successful" & @CRLF)
    EndIf

    _SQLite_Close($oDB1)
    _SQLite_Shutdown()

EndFunc

Scite output:

>"C:\Program Files (x86)\AutoIt3\SciTE\..\AutoIt3.exe" /ErrorStdOut "D:\Scripts\......au3"    
+ SQliteDll: sqlite3.dll
+ DB1 Handle: 0x00EF27D8
+ DB2 Handle: 0x00EF9A28
! AttachErr[2] Library used incorrectly
>Exit code: 0    Time: 0.9089

[TheDcoder]

33 minutes ago, dmob said:

Do I have to re-explain the bug or can I just link to this topic?

You should definitely link to the this topic, but copy-pasting your first post is also an option

Also including your code sample is a must!

[dmob]

I'll wait until someone actually confirms it's a bug and not old-age ...

[jchd]

The error has nothing to do with how the include works.

When you create a new SQLite database, it doesn't actually exists until you really write to the DB file.  That is, you need to create a DDL element (table) else the file remains empty.

[jchd]

Also, the statement with attach is erroneous: you use -1 as the DB handle, which refers to the last handle used (which is $oDB2) but it's invalid after having closed the DB.

Change that line into:

    Local $vRet = _SQLite_Exec($oDB1, $sQry)

and everything should work fine.

[dmob]

14 minutes ago, jchd said:

The error has nothing to do with how the include works.

I beg to differ. The UDF does actually clear the last used DB handle....

 

5 minutes ago, jchd said:

Also, the statement with attach is erroneous: you use -1 as the DB handle, which refers to the last handle used (which is $oDB2) but it's invalid after having closed the DB.

After having closed DB2, I would expect to still be able to use $oDB1, which IMHO should then be the last opened DB.

 

Are you thus implying the UDF was designed to use only one database at a time?

Edited June 16, 2020 by dmob

[jchd]

The code clears the handle passed, just as announced.

5 minutes ago, dmob said:

After having closed DB2, I would expect to still be able to use $oDB1, which IMHO should then be the last opened DB.

You can use $oDB1, but it isn't the last handle used!  That the handle refers to an open or closed DB is irrelevant and a completely different question.

Edited June 16, 2020 by jchd

[jchd]

BTW I personnally regard this use of -1 to refer to something of the past in several functions spread in various UDFs to be undue laziness and a call for bugs.

Few years ago I had to actually use AutoIt for my own needs and had to handle up to 5 database connections at a time, using a large number of high-level functions.  It would have been an unmanageable nightmare to try to use -1 since the "last connection used" was such a moving target.

[dmob]

27 minutes ago, jchd said:

That the handle refers to an open or closed DB is irrelevant and a completely different question.

32 minutes ago, dmob said:

which IMHO should then be the last opened DB

I should rephrase that and say "Should then be the last opened OPEN database. I would NOT try to access a DB I just closed,

nor would I expect its handle to be valid.

 

Anyhow, if it's not a bug that's ok, but the SQLite_Close function still exhibits "unexpected & possibly unwanted behaviour".

We can consider this topic closed since I have found the problem and a workaround.

Edited June 16, 2020 by dmob

[Melba23]

dmob,

Quote

Should then be the last opened OPEN database

That would be asking a lot of AutoIt. Throughout AutoIt "-1" is only used to denote "last created", not "last available" - which is all AutoIt should be expected to do. Expecting it to revert back through some form of GUI/control creation lineage is way beyond anything that could be reasonably expected.

And I agree totally with jchd that its use is to be strongly discouraged in anything but the very simplest scripts.

M23

[jchd]

It may not be the behavior you expect, but it conforms to the specification (last used handle)... and legacy code.

[dmob]

20 minutes ago, Melba23 said:

Throughout AutoIt "-1" is only used to denote "last created", not "last available"

That's fine with me, as I mentioned the hack I made satisfies both conditions: Once the last (when multiple DBs open) opened DB is closed, the previously opened "becomes" the last opened (__g_hDB_SQLite or -1 "points" to the last DB in the internal list of open DBs) until all DBs are closed, then the internal pointer ($__g_hDB_SQLite) is set to zero (when ALL opened DBs are closed) .

Edited June 16, 2020 by dmob

[jchd]

You're again confusing "last open" and "last used" but it's OK if you've found a way to make things work the way you need.

[dmob]

5 minutes ago, jchd said:

You're again confusing "last open" and "last used"

Pardon me, English aint my first language, I'm referring to the last database in the list of OPEN Dbs.

Edited June 16, 2020 by dmob

[dmob]

5 minutes ago, jchd said:

found a way to make things work the way you need.