• Welcome to SQLitening Support Forum.
 

News:

Welcome to the SQLitening support forums!

Main Menu
Menu

Show posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Show posts Menu

Messages - Fim

#2
"IF slLock("fim") THEN
ELSE
slUnlock("fim")
END IF"

No,I am using OPEN LOCK_FIL_NAMN FOR OUTPUT AS #TEST_LOCK_FIL
#3
Nothing is going well for me.
I've tried all sorts of solutions, but it's always something small that fails.
So I have decided to use file system and lock a file by doing "open output" in my main program.
Then when I start a new instance of the main program, I count the number of locked files by trying to do "open output".
In this way, for each new instance of my main program, I can report how many users are running.
I appreciate your commitment to finding a solution, Thank you.
This is what my program looks like now:

RAKNING_ANTAL_ANVANDARE:
'=======================
'
' I tråden BAKGRUND som finns med i alla kommadoprogram + WINOVA
' så sker en låsning i form av OPEN OUTPUT av en fil
' vars namn är IP-adressen. Det finns mer utförlig beskrivning där.

' Nu är det rätt enkel, vi går igenom alla registrerade IP-adresser i tabellen INL.
' För varje IP-adress undersöker vi om det finns en låst fil namnet IP-adress.
' Görs med försök av en OPEN OUTPUT.
' Lyckas vi med filöppningen, måste vi omgående släppa låsning med CLOSE och
' sedan gå  vidare till nästa IP-adress.
' Är filen låst, räknar vi upp antalet användare och går vidare till nästa IP-adress.
' Denna metod verkar vara helt vattentät, har testkört med över 100 instanser ocg 5 olika IP-adresser.

RAA_START:
    ANTAL_ANVANDARE = 0
    KOM.SQL_SATS = "SELECT * FROM INL"
    CALL INLIO(KOM, INL, "SQLS")
    TEST_LOCK_FIL = FREEFILE

RAA_NASTA:
    CALL INLIO(KOM, INL, "GN")
    IF LANGD(KOM.SVAR) > 0 THEN GOTO RAA_EXIT

RAA_LOCK_FORSOK:
    ON ERROR GOTO 0
    ERR = 0
    LOCK_FIL_NAMN =  TRIM$(INL.IP_ADRESS) + ".INLOGGAD"
    ERR = 0
    OPEN LOCK_FIL_NAMN FOR OUTPUT AS #TEST_LOCK_FIL
    SVAR = ERRCLEAR
    IF SVAR <> 0 THEN
        INCR ANTAL_ANVANDARE
        GOTO RAA_NASTA
    END IF
    CLOSE #TEST_LOCK_FIL
    GOTO RAA_NASTA
RAA_EXIT:

ANTAL_ANVANDARE are NUMBER_OF_USERS
#4
I think this is easier.
RETURNCODE = slSetRelNamedLocks(LOCK_NAME, "T0", "SELECT * FROM INL LIMIT 0", 0, "E0")

RETURNCODE = 0, unlocked
RETURNCODE = 11, locked
In neither case does an error code appear on the screen.
How about that?
#5
You have a better memory than I
I am 81 years.
#6
Ok.
I'm working on my solution.
/Fim W.
BTW Happy Christmas
#8

Only way I have come up with is to try to do a lock, if it succeeds, ReturnCode = 0, then the object is not locked. If ReturnCode <> 0, the object is locked.
If you have made a lock during this examination, you should release the lock immediately.

Fim W.
#9
Now it wasn't the select statements that were the problem, they work as they should. The problem is that the first select statement takes 6 seconds but the next select statement only takes 0.6 seconds.
#10
In a program to find words from a database of 4 million words, I have a timing problem.
If I execute a select statement, for example
SELECT * FROM WORDLIST WHERE LENGTH = 10
and then downloads all the selected data, it takes 6 seconds on a completely just started PC. The second time when I execute another select statement, SELECT * FROM WORDLIST WHERE LANGD = 12, and then retrieve all the selected data, it takes 0.6 seconds. If I exit the program without restarting the PC, restart the program, all the select statements take less than a second.
I've come so far in my research that it's not the Select statement itself that takes time, it's the subsequent fetching of data that takes time.
Anyone have a good explanation?
#11
Many thanks for an exhaustive answer.
/Fim W.
#12
Can a PDF file be stored in a database, if so how?
/Fim W.
#13
Thanks for the advice and instructions. But I have decided to go another way to solve my problem, and it has gone well
#14
How about this in SQlitening.bas
#15
Many thanks. I should have read the manual better.
/Fim W.