Login ProductsSalesSupportDownloadsAbout |
Home » Technical Support » DBISAM Technical Support » Support Forums » DBISAM General Discussion » View Thread |
Messages 1 to 10 of 16 total |
CopyTable Problem |
Thu, Feb 16 2006 5:19 PM | Permanent Link |
Ted K | Using DBISAM C/S 3.30 Win XP
Some of my clients are having a problem with my application which uses the CopyTable method on a large table (200 megs). After approx 4-5 minutes the screen "greys out" and when they try to close the application the "not responding" message appears. The weird thing is that when they check the table to be copied to in dbsys, it's there! Any ideas?? |
Fri, Feb 17 2006 4:01 AM | Permanent Link |
"Jose Eduardo Helminsky" | Ted
My suggestion. Check the source of DBSys and you will find what is different from your code. Eduardo |
Fri, Feb 17 2006 4:32 AM | Permanent Link |
Roy Lambert NLH Associates Team Elevate | Ted
I had a user where he'd get the app greyed out after bringing another app to the foreground - eventually it turned out to be a screensaver/password messing things up. Roy Lambert |
Fri, Feb 17 2006 10:43 AM | Permanent Link |
Ted K | Thanks, but I already have done that and the only difference I could see was that in DBSYS a procedure is assigned to the OnCopyProgress event handler of the
SaveTableDlg component. I assumed this was only necessary for the progress gauge in dbsys, which I did not use. My question is: Why can the copyTable method not be used on it's own, or is there something else required for large tables? "Jose Eduardo Helminsky" <contato@hpro.com.br> wrote: Ted My suggestion. Check the source of DBSys and you will find what is different from your code. Eduardo |
Fri, Feb 17 2006 11:47 AM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | Ted,
<< Some of my clients are having a problem with my application which uses the CopyTable method on a large table (200 megs). After approx 4-5 minutes the screen "greys out" and when they try to close the application the "not responding" message appears. The weird thing is that when they check the table to be copied to in dbsys, it's there! Any ideas?? >> Is the destination table present ? This sounds like a screen redraw issue. What happens if you hook up an OnCopyProgress event and simply call Application.ProcessMessages inside of it ? That should fix any screen redraw issues. -- Tim Young Elevate Software www.elevatesoft.com |
Fri, Feb 17 2006 12:32 PM | Permanent Link |
Bernd Kuhlmann | Ted,
> Using DBISAM C/S 3.30 Win XP > > Some of my clients are having a problem with my application which uses the > CopyTable method on a large table (200 megs). After approx 4-5 minutes the > screen "greys out" and when they try to close the application the "not > responding" message appears. The weird thing is that when they check the > table to be copied to in > dbsys, it's there! Any ideas?? Microsoft has changed the behaviour in Windows XP. From http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winui/winui/windowsuserinterface/windowing/messagesandmessagequeues/aboutmessagesandmessagequeues.asp (or search in google for: windows xp not responding redraw) --- Microsoft Windows XP: If a top-level window stops responding to messages for more than several seconds, the system considers the window to be not responding. In this case, the system hides the window and replaces it with a ghost window that has the same Z order, location, size, and visual attributes. This allows the user to move it, resize it, or even close the application. However, these are the only actions available because the application is actually not responding. When in the debugger mode, the system does not generate a ghost window. --- So a code fragment like this: begin mytable.first; while not mytable.eof do begin doSomething; mytable.next; label.caption:=counter; update;// this doesn't really help under windows xp end; ShowMessage('Done'); end; which runs fine under windows 2000 shows the behaviour you describe under windows XP. The only solutions i am aware of are 1. use application.processmessages (and make sure that all buttons are disabled) 2. use a seperate thread Bernd Kuhlmann PS: to make this even worse the ShowMessage window is sometimes "shown" behind the current window. Sometimes you can bring the ShowMessage window to front with Alt-Tab. |
Fri, Feb 17 2006 1:06 PM | Permanent Link |
Roy Lambert NLH Associates Team Elevate | Bernd
Bloody hell! Does that mean that if I have any loops which might take a while I have to use application.processmessages and slow it down!? Roy Lambert |
Fri, Feb 17 2006 1:16 PM | Permanent Link |
"J. Lee" | Yes, or use threads. I always place user feedback just as important as
raw application speed. ~J. Lee Roy Lambert wrote: > Bernd > > > Bloody hell! > > Does that mean that if I have any loops which might take a while I have to use application.processmessages and slow it down!? > > Roy Lambert > |
Fri, Feb 17 2006 2:06 PM | Permanent Link |
Roy Lambert NLH Associates Team Elevate | J.
(nice name From the link "If a top-level window stops responding to messages for more than several seconds, the system considers the window to be not responding." I agree user feedback is of high importance but several seconds is just madness. Some loops its just not worth giving feedback - I normally just change the cursor - and in some application.processmessage is positively dangerous. Roy Lambert |
Fri, Feb 17 2006 2:31 PM | Permanent Link |
Sean McCall | Finally I understand what I have been seeing! We have
maintenance functions launch from a window with progress bars that are updated with Application.ProcessMessages between processing tables... some operations on very large tables take a while between progress updates and calls to Application.ProcessMessages. Once XP has decided that a window is not responding (usually because the user makes another window the top window), the progress bars no longer update even when Application.ProcessMessages is called. The screen will not return to normal operation until all the processing is completed and presumeably the mouse/keyboard input is fully handled again. The problem is that user thinks the program is locked... the addition in the caption of "(not responding)" on XP's fake window just re-enforces this notion. We warn the users before starting that on XP the screen may stop updating. I wish there were a way to turn off this "feature" or that Microsoft had at the sense to change "(not responding)" to something less alarmist like '(working)' or '(processing)'. Even better, the could have added a moving icon or animated background color to the caption to show it is working. Sean Roy Lambert wrote: > J. > > > (nice name > > From the link > > "If a top-level window stops responding to messages for more than several seconds, the system considers the window to be not responding." > > I agree user feedback is of high importance but several seconds is just madness. Some loops its just not worth giving feedback - I normally just change the cursor - and in some application.processmessage is positively dangerous. > > Roy Lambert > |
Page 1 of 2 | Next Page » | |
Jump to Page: 1 2 |
This web page was last updated on Thursday, March 28, 2024 at 08:36 AM | Privacy PolicySite Map © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? E-mail us at info@elevatesoft.com |