Paradox Community

Items in pnews.paradox-client_server

Subject:Re: Performance Issue Mouse
Date:Fri, 27 Apr 2018 12:19:17 +1000
From:Tom Krieg <REMOVEtomkCAPITALS@sdassociates.com.au>
Newsgroups:pnews.paradox-client_server
Thies,

I suspect your problem is with the single SQL statement per record, from 
a TCursor. Each record in your TCursor triggers -

Paradox -> ODBC (Cursor changes to SQL hourglass)
ODBC -> SQL Server Insert
SQL Server -> ODBC (returnm code)
ODBC -> Paradox (return)
Cursor changes to hourglass

This is a slow as molasses and inefficient. Because the mouse changes to 
SQL Hourglass and back to Arrow (and flickers) FOR EACH TCuror -> 
Insert, Paradox will trigger at least 2 mouse events for each record 
(maybe more).

Moving the cursor so the cusror events aren't triggered solves some of 
the problem but you still have the inefficiency of the insert. Try it 
with a bulk copy and compare the times.

You should do this by creating CSV and doing an IMPORT or Bulk Copy.

I think it's
BULK
INSERT INTO <tablename> FROM <CSV filename>;
GO;


I haven't used SQL Server for 10 years so I may have it wrong, but you 
should use a bulk copy with Paradox and ODBC when inserting a large 
number of records.

Thies Grimm wrote:
> Hi Leslie,
> 
> so I made a new form - just one buttom - nothing else.
> 
> pushbutton:
> 
> 1. enumRTLConstants(":priv:__tblRTLConstants.db")
> 2. read ":priv:__tblRTLConstants.db" in TCursorInMemory
> 3. delete ":priv:__tblRTLConstants.db"
> 
> 4. dataBase handle to my SQL Server (MS SQL 2008 R2 via ODBC)
> 5. drop temp table #PerformanceCheck
> 6. create new #PerformanceCheck
>     itemSQL =
>        SQL
>           CREATE TABLE #tblPerformanceCheck
>              (    ID INTEGER
>                 , GroupName varCHAR(32)
>                 , ConstantName varCHAR(48)
>                 , TypeName  varCHAR(48)
>                 , Value varCHAR(64)
>                 , PRIMARY KEY (ID))
>        endSQL
> 7. Start time measurement liZeit = CPUClockTime()
> 8. scan tcInMem
>       Insert INTO #PerformanceCheck every record
>       2375 single SQL Statements
>     endScan
> 9. Stop Time measurment liZeit = CPUClockTime() - liZeit
> 10. Check #tblPerformanceCheck
> 11. clean up
> 
> On my machine about 8400 MS, on my Notebook about 330000 ms.
> If the user moves the mouse out of the Paradox Windows everything is much
> faster. So my Workaround:
> 
> workaround
> ==========
> Change 8.
>     pntMouse = getMouseScreenPosition()
>     setMouseScreenPosition(-10,-10)
>     scan tcInMem
>       Insert INTO #PerformanceCheck every record
>       2375 single SQL Statements
>     endScan
>     setMouseScreenPosition(pntMouse )
> 
> On my machine about 7900 MS, not much of a difference, but on my Notebook
> about 11000 ms. This is 30 times faster!
> It is a new Notebook, i5 processor.
> 
> 
> So I tried setCapture:
> 
> setCapture
> ==========
> uses "user32.dll"
>     SetCapture(hWnd cLong) cLong
>     ReleaseCapture() cLong
>     FindWindow(ClassName CPTR, WindowName CPTR) CLONG
> endUses
> 
> Change 8.
>     liHandle = FindWindow("PDOXWINDESKTOP", app.getTitle())
>     SetCapture(liHandle)
>     scan tcInMem
>       Insert INTO #PerformanceCheck every record
>       2375 single SQL Statements
>     endScan
>     ReleaseCapture()
> 
> No difference. Still very slow. still flickering mouse.
> Should I try to use another Windows handle. I tried a DOS Window - no difference.
> I think, the executeSQL is the reason for the flickering.
> 
> Any ideas?
> 
> Thanks a lot!
> 
> Thies
> 
> 
> Leslie <"ViaThe List"@NOSPAM.com> wrote:
>> Strange as this was a common solution back in the day especially with a
> 
>> Sybase database.
>>
>> Are you sure you specified an appropriate Window Handle - remember a
>> hidden Window cannot be used but also it should not be one of your
>> current Windows either because they are likely the problem.
>>
>> So assuming all is ok with the hWnd then it implies that somewhere in
>> the Paradox system (in all probability in your code) the Mouse Messages
> 
>> are in fact triggering an action which causes the delay.
>>
>> You have just about proven this fact by your statement that if the user
> 
>> moves the mouse back over the Window, after you programmatically moved
>> it, while the SQL job still runs then it slows.
>>
>> To be more specific, my guess is that either a Window or a Field is
>> trapping and acting upon either the WM_MOUSEMOVE or WM_NCMOUSEMOVE
>> messages. Unless you are using TrackMouseEvent() to enable WM_HOVER and
> 
>> WM_LEAVE directly.
>>
>> So, to be certain I would use WinSpy++ to see what messages are being
>> sent to which underlying Window while the flickering occurs.
>>
>> Lastly, what happens with the performance if you just hide the mouse
>> cursor does performance improve or not.
>>
>> It is an interesting problem.
>> Leslie.
>>
>> On 26/04/2018 9:36 PM, Thies Grimm wrote:
>>> Hi Leslie,
>>>
>>> very nice idea, but doesn't work.
>>>
>>> As Workaround I use something like this (moving the mouse off the Desktop):
>>>
>>> pntMouse = getMouseScreenPosition()
>>> setMouseScreenPosition(-10,-10)
>>>
>>> ... doing my SQL-Jobs ...
>>>
>>> setMouseScreenPosition(pntMouse)
>>>
>>>
>>> The disadvantage is that there is no mouse at all during the SQL-Jobs,
> but
>>> as long as the user doesn't move the mouse back it is fast - much faster.
>>> On the Notebook 10 times faster!
>>>
>>> I would love to get any idea how to solve that issue in a better way.
>>>
>>> Thies
>>>
>>>
>>>
>>> Leslie <"ViaThe List"@NOSPAM.com> wrote:
>>>> Try SetCapture() and ReleaseCapture()
>>>>
>>>> On 25/04/2018 12:45 AM, Thies Grimm wrote:
>>>>> Hi,
>>>>> How can I stop the mouse flickering during SQL-jobs.
>>>>> When I move the mouse out of the paradox-window the action is almost
> two
>>>>> times faster!
>>>>> SetMouseShape(NoMouse, True) doesn’t work either delayScreenUpdates.
>>>>>
>>>>> Thies
>>>>>
>>>>
>>>> ---
>>>> This email has been checked for viruses by AVG.
>>>> http://www.avg.com
>>>>
>>>
> 


Copyright © 2004 thedbcommunity.com