|
|
Post by metro on Feb 2, 2024 23:48:57 GMT -5
This maybe of interest....
|
|
|
|
Post by metro on Feb 2, 2024 23:58:21 GMT -5
|
|
|
|
Post by badbug on Mar 8, 2024 10:27:07 GMT -5
I have been using Run Basic with mySQL instead of SQLite so got rid of the locks.
Problem now is the RUN command . Every time you use it to run another program, it leaves something behind from the program that ran it.
After a while you memory skyrockest and you have to restart RB.
So I'm thinking that I can put in the HTML code the next program to run.
Do you think that will work because I would be bypassing the normal way to run a program.
If that works, then RB will be in the game again.
The real fix of course is to fix the code itself, but RB doesn't seem to have many updates in the last 6 months..
Frank... My dad Dan said hi..
|
|
|
|
Post by Carl Gundel on Mar 8, 2024 12:01:24 GMT -5
I have been using Run Basic with mySQL instead of SQLite so got rid of the locks. Problem now is the RUN command . Every time you use it to run another program, it leaves something behind from the program that ran it. After a while you memory skyrockest and you have to restart RB. So I'm thinking that I can put in the HTML code the next program to run. Do you think that will work because I would be bypassing the normal way to run a program. If that works, then RB will be in the game again. The real fix of course is to fix the code itself, but RB doesn't seem to have many updates in the last 6 months.. Frank... My dad Dan said hi.. Hmm. Interesting sounding problem. Maybe a bug in RB, I'm not sure. Can you simply reuse the program that you are RUNning, over and over? |
|
|
|
Post by Rod on Mar 8, 2024 12:07:24 GMT -5
I was just wondering if the run program actually reaches an END statement? Just a guess you may have that covered.
|
|
|
|
Post by pierre on Mar 8, 2024 17:51:01 GMT -5
I have been using Run Basic with mySQL instead of SQLite so got rid of the locks. Problem now is the RUN command . Every time you use it to run another program, it leaves something behind from the program that ran it. After a while you memory skyrockest and you have to restart RB. So I'm thinking that I can put in the HTML code the next program to run. Do you think that will work because I would be bypassing the normal way to run a program. If that works, then RB will be in the game again. The real fix of course is to fix the code itself, but RB doesn't seem to have many updates in the last 6 months.. Frank... My dad Dan said hi.. Wow, badbug, that 's speedy ! A few days ago, you were still lost in the middle of Run BASIC's SQLite locks, and now you are already using it with MySQL ? Something in my mind is telling me that you are not the beginner you pretend to be.... Would you be willing to share some snippets of your code, just to show us how to connect to MySQL from Run BASIC ? Thanks in advance. By the way, say hello to daddy from me. pierre |
|
|
|
Post by pierre on Mar 9, 2024 5:12:00 GMT -5
Now more seriously,
The persistent SQLite locks and the Run command's behaviour you describe may be related:
Run BASIC is not per se holding the locks, it continues to hold the complete file. You can see this by doing the following:
Close your file and close the browser, but do not close the Run BASIC console. Then - what you should normally never do of course -
go to the corresponding project folder and try to kill your *.bas program. Your operating system (for me Windows) will give you a 'file in use' error. You have to close Run BASIC before accessing your file. I have seen that in other Basic's. (I believe LB5 is not behaving like this).
So it is quite possible that your different programs successively called by the Run command are piling up in memory.
As far as the SQLite locks are concerned, I can only speak of the locks I simulate myself. I have no experience in production.
I found the following workaround:
Trap the error in a 'on error goto' statement and rollback the transaction. Then you can continue your work without leaving Run
BASIC. The lock is released. (verified also in DB Browser).
There is however a caveat: In some way, the cursor affected by the database lock does not work correctly anymore. It can write
again, but the transaction remains in its own memory cache and does not reach the database.
Workaround: disconnect and reconnect the cursor, the way recommended by Carl since the beginning. That cleans it all up.
By the way, this is precisely what the 'lock test monster' fix in LB5 does. 'disconnect-reconnect'. I may be wrong, but I wouldn't be
surprised at all if it was exactly that.
If desired, I can post a small example, but there is almost no interest for SQLite on this forum.
All this being said, I am still interested in the way you connect Run BASIC to MySQL.
pierre
|
|
|
|
Post by metro on Mar 9, 2024 7:08:13 GMT -5
If desired, I can post a small example, but there is almost no interest for SQLite on this forum. All this being said, I am still interested in the way you connect Run BASIC to MySQL. pierre he told Dan that he used FreeBasic to code a "shim" as he described it.
Dan also posted a great example of rolling back a transaction, works with LB5/RB
'The DB has 3 fields..
'The first 2 inserts work.
'The 3rd insert fails because it tries to insert 4 fields into the 3 field table.
'The on error causes it to go the [rollback]
'It gets the number of rows inserted, and correctly reports 2.
'It executes the ROLLBACK
'Now when it gets the rows inserted it is 0. That's because the BEGIN TRANSACTION surrounded all the inserts..
'CREDIT DAN 2011
db$=":memory:"
'=========================================
'LINUX OS REQUIRES PATH
sqliteconnect #mem, db$ ,"/usr/lib/x86_64-linux-gnu"
'sqliteconnect #sql,,"/usr/lib/i386-linux-gnu"
'=========================================
mem$ = "CREATE TABLE tempTbl (aa text,bb text,cc text);"
#mem execute(mem$)
#mem execute("BEGIN TRANSACTION")
on error goto [rollback]
mem$ = "INSERT INTO tempTbl VALUES('a1','b1','c1')"
#mem execute(mem$)
print "Insert ok:";mem$ ' first insert works
mem$ = "INSERT INTO tempTbl VALUES('a2','b2','c2')"
#mem execute(mem$)
' second insert works
print "Insert ok:";mem$
mem$ = "INSERT INTO tempTbl VALUES('a4','b3','c3','d3')"
#mem execute(mem$) ' this fails and trips the on error
print "Insert ok:";mem$
#mem execute("COMMIT TRANSACTION")
print "commited"
wait
[rollback]
#mem execute("SELECT * FROM tempTbl")
rows = #mem ROWCOUNT()
print "Rolls inserted:";rows
#mem execute("ROLLBACK TRANSACTION")
print "Roll back"
#mem execute("SELECT * FROM tempTbl")
rows = #mem ROWCOUNT()
print "Rolls inserted:";rows
#mem DISCONNECT()
WAIT
|
|
|
|
Post by pierre on Mar 9, 2024 13:09:06 GMT -5
Hi metro !
MySQL:
I remember Jerry's post on the Run BASIC forum. But that goes back to the year 2020 and since then, no other ideas on the subject.
Indeed, let's hope that Dan & Son will have something more to tell us ......
SQLite:
The example you are showing for the rollback statement is the one I used for my own code in Run BASIC. The problem is that when
we roll back a database lock, something seems to remain in memory, kind of "scotched" to the cursor, I don't know how to describe it.
It changes the subsequent behaviour of the affected cursor. The only way to get rid of it, is the 'disconnect-reconnect' method.
It must be something due to the SmallTalk SQLite interface, or to Run BASIC itself. I never read about it on the official SQLite forum.
The proposed fix is not necessary in LB5, thanks to the already applied 'lock test monster' fix.
For those interested, here is a small example written in Run BASIC:
First time you run it:
Mind that the words "database is locked" are not written by me. They come directly from the special variable 'Err$'.
Using the 'on error goto' method, we avoid the ugly lock in Run BASIC and rolling back the transaction, the program flow can continue.
We see that #Y can write after #X's commit, but the results are only visible in #Y's memory cache.
Second time you run it:
unquote the 4 lines of the so-called 'lock test monster fix' and you can see that #Y eventually writes to the database.
'---------------------------------------------------------------------------------------------------------------------------------------
'delete mode
sqliteconnect #X, "foo.db"
sqliteconnect #Y, "foo.db"
#X execute("create table if not exists t (a text)")
X execute("delete from t")
print "#X starts a transaction"
#X execute("begin transaction")
print "X writes but does not commit"
#X execute("insert into t values ('hello world')")
print
print "Y tries to write"
on error goto [nextLine]
#Y execute("begin transaction")
#Y execute("insert into t values('bye,bye')")
#Y execute("commit transaction")
[nextLine]
print Err$
#Y execute("rollback transaction")
print
print "transaction rolled back"
print
print "X commits"
#X execute("commit transaction")
print
'print "locktest monster fix"
'#Y disconnect()
'sqliteconnect #Y, "foo.db"
'print
print "#Y reads"
#Y execute("select * from t")
while #Y hasanswer()
#row = #Y #nextrow()
a$ = #row a$()
print a$
wend
print
print "#X reads"
#X execute("select * from t")
while #X hasanswer()
#row = #X #nextrow()
a$ = #row a$()
print a$
wend
print
print "#Y writes"
#Y execute("insert into t values('bye,bye')")
print
print "#Y reads"
#Y execute("select * from t")
while #Y hasanswer()
#row = #Y #nextrow()
a$ = #row a$()
print a$
wend
print
print "#X reads"
#X execute("select * from t")
while #X hasanswer()
#row = #X #nextrow()
a$ = #row a$()
print a$
wend
print
'--------------------------------------------------------------------------------------------------------------------------------------
|
|
|
|
Post by metro on Mar 9, 2024 20:15:35 GMT -5
Hi metro ! MySQL: I remember Jerry's post on the Run BASIC forum. But that goes back to the year 2020 and since then, no other ideas on the subject. Indeed, let's hope that Dan & Son will have something more to tell us ...... Second time you run it: unquote the 4 lines of the so-called 'lock test monster fix' and you can see that #Y eventually writes to the database. G'Day pierre, Great job, lets see if the master & apprentice have luck with using your solution. yes it would be great to see the code they came up with to use MySQL
It's a shame I can't use RB on a 64b Linux system anymore (for years).
|
|
|
|
Post by metro on Mar 9, 2024 20:57:28 GMT -5
I was just wondering if the run program actually reaches an END statement? Just a guess you may have that covered. Just to confirm what Rod stated , intro-lesson8p2.rtf has the following
|
|
