Home > Archive > Clarion > June 2006 > Beautifying Key Rebuild with Progress Indicator Window?
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Beautifying Key Rebuild with Progress Indicator Window?
|
|
| M.P. van Dobben de Bruijn 2006-06-20, 7:55 am |
|
Hi,
Am trying to push all functionality of an
old DOS application from another company at
a customers site into an Clarion for Win solution.
Now, we do not want to touch their
DOS FoxPro databases to prevent getting
blamed if anything goes wrong on that end.
We cannot spend the time and energy to solve that.
So we copy the files over for the time being
to another directory on a <g> Linux server. And
work from those copies as we are in the phase of
creating the report-modules etc. first. We are using
a lot of different keys/indexes than the FoxPro applica-
tion of course. So these are to be build from scratch eve-
ry time the application is first opened (copying for repor-
ting purposes is limited to one-two times a day for now, so
there is not a problem there). But this building of the keys
on some of the larger databases over an old 10 mpbs takes ages.
Eh .... <g> in fact it is only five minutes.
But the users gets  , after announcing
that it will (re-) build the key the windows an-
nounding that disappears after an OK (could'nt we
get rid of that with a simple progress procedure, i.e.
step 1 - rebuilding key .... for database ... etc. etc)
and there is no progress indicator as with the repors etc.
Anybody ever seen a more elegant solution or this?
best regards
from Leeuwarden
Peter van Dobben de Bruijn
--
regards from Leeuwarden
Peter van Dobben de Bruijn
----
reply2usenet-2005 .at. The-Net-4U.com (.at. becomes @)
----
| |
| pblais@odstrategies.org 2006-06-24, 7:55 am |
| I think the problem is you do a lot. Maybe too much. There are ways to
do this but perhaps using a different DB would be as fast. You might
try to read and write the tables to TPS format using a LOGOUT / COMMIT
instead of using a Foxpro format. Rebuilding all those new keys can't
be easy and maybe a new format could be a slight bit faster. A TPS
LOGOUT / COMMIT is pretty fast.
In the end you are the "tail on the dog". I write an application that
does something like you do. It's an app written by idiots that I wrote
a secondary EXE to do all the things they can't do. It's a niche job
but it pays a few bills. I do other things to really make a living but
the people are nice and they really need the service.
Sometimes it's more important to know you are the tail and not the
dog.
On 20 Jun 2006 13:07:38 GMT, "M.P. van Dobben de Bruijn"
<Reply2Usenet-2005@The-Net-4U.com> wrote:
>Anybody ever seen a more elegant solution or this?
---------------------------------------
Paul Blais - Hayes, Virginia
| |
| M.P. van Dobben de Bruijn 2006-06-24, 7:55 am |
| On Thu, 22 Jun 2006 23:39:49 UTC, pblais@odstrategies.org wrote:
> I think the problem is you do a lot. Maybe too much. There are ways to
> do this but perhaps using a different DB would be as fast. You might
> try to read and write the tables to TPS format using a LOGOUT / COMMIT
> instead of using a Foxpro format. Rebuilding all those new keys can't
> be easy and maybe a new format could be a slight bit faster. A TPS
> LOGOUT / COMMIT is pretty fast.
Thanks. But this is not the moment to change
all that around also. For the time being the pro-
duction system will be the old FoxPro DOS App
(for editing and adding) and we are going to take
over the reporting modules from that one step by step.
The beauty of Clarion is of course that you
are not forced to do an database-file-format or
database engine change when you are not up
to it yet. As said, I think this is not the moment yet.
As soon as we have the reporting working
we'll start on the editing / updating thing and
in the end they'll retire the old Foxpro DOS app.
At a certain point in time this whole process
of copying the FoxPro datafiles (for safety rea-
sons as not to corrupt those so no fingerpointing
about who is to blame can erupt) and therefore the
rebuilding of the keys will then automatically vanish.
Of course we could now go over to TPS
but perhaps there are reasons to select so-
meting else later, so I am in no hurry if not forced.
> In the end you are the "tail on the dog". I write an application that
> does something like you do. It's an app written by idiots that I wrote
> a secondary EXE to do all the things they can't do. It's a niche job
> but it pays a few bills. I do other things to really make a living but
> the people are nice and they really need the service.
>
> Sometimes it's more important to
> know you are the tail and not the dog.
I know, but we are planning on to become the dog.
The old dog and the new tail will have to
coexist peacefully for the time we need for that.
| |
| IGM-Man 2006-06-24, 7:55 am |
| If you know that these indexes will need to be rebuilt, insert before
the files are opened a test:
Try to open the file, if you get the Invide Index error, call a window
that SHOWS, REBUILDING FILE, PLEASE WAIT (THIS COULD TAKE UP TO 10
MiNUTES) or something like that. then OPEN the file in non-shared
access and BUILD()
when done close the temp window.
This will at least give a visual that you are working.
Ken
M.P. van Dobben de Bruijn wrote:
> On Thu, 22 Jun 2006 23:39:49 UTC, pblais@odstrategies.org wrote:
>
>
> Thanks. But this is not the moment to change
> all that around also. For the time being the pro-
> duction system will be the old FoxPro DOS App
> (for editing and adding) and we are going to take
> over the reporting modules from that one step by step.
>
> The beauty of Clarion is of course that you
> are not forced to do an database-file-format or
> database engine change when you are not up
> to it yet. As said, I think this is not the moment yet.
>
> As soon as we have the reporting working
> we'll start on the editing / updating thing and
> in the end they'll retire the old Foxpro DOS app.
>
> At a certain point in time this whole process
> of copying the FoxPro datafiles (for safety rea-
> sons as not to corrupt those so no fingerpointing
> about who is to blame can erupt) and therefore the
> rebuilding of the keys will then automatically vanish.
>
> Of course we could now go over to TPS
> but perhaps there are reasons to select so-
> meting else later, so I am in no hurry if not forced.
>
>
> I know, but we are planning on to become the dog.
>
> The old dog and the new tail will have to
> coexist peacefully for the time we need for that.
| |
| Udo Cizelj 2006-06-24, 7:55 am |
| Hi Peter,
As Paul already said - use TPS.
Instead of just copying files tod the server - transfer files with an
conversion routine DBF-TPS.
If I remember corectly some user had problems with DBF/FoxPro format
especially regarding the internationalisation, keys etc.
--
Udo Cizelj
Maribor, Slovenia
CW6.3PE,IPD2.3,WinXPprof,SP2
"M.P. van Dobben de Bruijn" <Reply2Usenet-2005@The-Net-4U.com> wrote in
message news:Q3C8iT21jGKT-pn2-MdTnZMX69L1i@localhost...
>
>
>
> Hi,
>
> Am trying to push all functionality of an
> old DOS application from another company at
> a customers site into an Clarion for Win solution.
>
> Now, we do not want to touch their
> DOS FoxPro databases to prevent getting
> blamed if anything goes wrong on that end.
>
> We cannot spend the time and energy to solve that.
>
> So we copy the files over for the time being
> to another directory on a <g> Linux server. And
> work from those copies as we are in the phase of
> creating the report-modules etc. first. We are using
> a lot of different keys/indexes than the FoxPro applica-
> tion of course. So these are to be build from scratch eve-
> ry time the application is first opened (copying for repor-
> ting purposes is limited to one-two times a day for now, so
> there is not a problem there). But this building of the keys
> on some of the larger databases over an old 10 mpbs takes ages.
>
> Eh .... <g> in fact it is only five minutes.
>
> But the users gets , after announcing
> that it will (re-) build the key the windows an-
> nounding that disappears after an OK (could'nt we
> get rid of that with a simple progress procedure, i.e.
> step 1 - rebuilding key .... for database ... etc. etc)
> and there is no progress indicator as with the repors etc.
>
> Anybody ever seen a more elegant solution or this?
>
> best regards
> from Leeuwarden
> Peter van Dobben de Bruijn
>
> --
> regards from Leeuwarden
> Peter van Dobben de Bruijn
> ----
> reply2usenet-2005 .at. The-Net-4U.com (.at. becomes @)
> ----
| |
|
| I wrote a fancy feedback version using progress bars which shows
(rough) remaining time to complete and allows pausing/aborting for file
rebuilding which is command line driven (could be from batch file).
Rebuilding files is best done outside your app to reduce chances that
the files are in use. You simply put in your file structure and
compile, once per file structure
It supports build/pack and auto-backup. Let me know if you want the
source.
HTH,
Paul
Udo Cizelj wrote:[color=darkred]
> Hi Peter,
>
> As Paul already said - use TPS.
> Instead of just copying files tod the server - transfer files with an
> conversion routine DBF-TPS.
> If I remember corectly some user had problems with DBF/FoxPro format
> especially regarding the internationalisation, keys etc.
>
> --
> Udo Cizelj
> Maribor, Slovenia
> CW6.3PE,IPD2.3,WinXPprof,SP2
>
>
>
> "M.P. van Dobben de Bruijn" <Reply2Usenet-2005@The-Net-4U.com> wrote in
> message news:Q3C8iT21jGKT-pn2-MdTnZMX69L1i@localhost...
| |
| pblais@odstrategies.org 2006-06-24, 7:55 am |
| So far I see good suggestions. A progress window helps make a process
seem faster. Just do that first as it helps more than small
improvements in speed. The conversion from Foxpro to TPS in my
original reply MIGHT be faster than re indexing a Foxpro file IF you
use LOGOUT / COMMIT. Just because FoxPro uses separate Index files is
not a reason you have to do it too. It's a mistake to think it is
assured to be quicker.
As a user I don;t care what format you use if I get what I want.
Rebuilding an index and not changing format is not different than
making a TPS file since you throw the Index away after you are done.
There is nothing a FoxPro format can do that you could not do faster
in TPS and all you do is change the driver. You don't have to alter
the original data and I wouldn't suggest you do that until you can get
rid of the old application. Then I would change the dictionary so you
don't rebuild indexes - ever. Imagine how fast it would be then.
The good part is the code you write is almost the same for TPS and
FoxPro. It's been a VERY long time sine I used FoxPro format (like
back when Window 3.0 was brand new). Foxpro was at it's peak back in
the olden days of DOS 3.0 when the Intel 286 chip was considered fast.
I can see you don;'t want to be the tail on the dog for very long.
Part of that is being better. You don't get ahead by being "no worse
than someone else". Given the age of this application I can't see how
you couldn't really make something very nice with modern tools that
does things that changes the way they do business in a big way.
Companies will pay for that type of improvement. You need to show them
something even small then they will pay. You don't really need to
start out being as bad as the old program first before you do
something smarter.
On 23 Jun 2006 11:26:24 GMT, "M.P. van Dobben de Bruijn"
<Reply2Usenet-2005@The-Net-4U.com> wrote:
>Thanks. But this is not the moment to change
>all that around also.
---------------------------------------
Paul Blais - Hayes, Virginia
| |
| M.P. van Dobben de Bruijn 2006-06-29, 7:55 am |
| On Fri, 23 Jun 2006 11:39:54 UTC, "IGM-Man" <ken.moyer@doodysicr.com> wrote:
> If you know that these indexes will need to be rebuilt, insert before
> the files are opened a test:
>
> Try to open the file, if you get the Invide Index error, call a window
> that SHOWS, REBUILDING FILE, PLEASE WAIT (THIS COULD TAKE UP TO 10
> MiNUTES) or something like that. then OPEN the file in non-shared
> access and BUILD()
> when done close the temp window.
>
> This will at least give a visual that you are working.
Thanks, that would do. It is only to prevent them thinking
that the system is locked and doing a CTRL-ALT-DEL etc.
On the other hand I am looking into the other advice
to import into an TPS-file (see also Yahoo-Group OZ Clarion)
again. Rereading those advices there and here and rethinking
about what is said, quietly sitting on a comfortable chair late friday-
afternoon <g> first quiet period for w s. Perhaps I'll combine it with
your advice if I do not go for your advice alone. I'll have to thinker with it.
--
regards from Leeuwarden
Peter van Dobben de Bruijn
----
reply2usenet-2005 .at. The-Net-4U.com (.at. becomes @)
----
| |
| M.P. van Dobben de Bruijn 2006-06-29, 7:55 am |
| On Fri, 23 Jun 2006 13:26:02 UTC, "Udo Cizelj" <udo_cizelj@amisDOTnet> wrote:
> Hi Peter,
>
> As Paul already said - use TPS.
> Instead of just copying files tod the server - transfer files with an
> conversion routine DBF-TPS.
> If I remember corectly some user had problems with DBF/FoxPro format
> especially regarding the internationalisation, keys etc.
I am (see other post) quietly re-thinking my strategy.
Do not expect characterset / internationalisation
problems at the current stage of affairs. It is an old
FoxPro DOS application and those tended to use in
Western Europe standard ANSI/OEM charactersets.
I am only trying to recreate the current reports
from it and then we are going to lure them in by
expanding on that and then make it even more fle-
xible by moving the database-editing to Clarion (while
the ultimate goal is of course being able to use it on internet)
--
regards from Leeuwarden
Peter van Dobben de Bruijn
----
reply2usenet-2005 .at. The-Net-4U.com (.at. becomes @)
----
| |
| M.P. van Dobben de Bruijn 2006-06-29, 7:55 am |
| On Sat, 24 Jun 2006 04:40:12 UTC, pblais@odstrategies.org wrote:
> So far I see good suggestions. A progress
> window helps make a process seem faster.
Which <g> reminds me of Bono lateral thinking
advice on secretaries travelling between floors on
a huge skyscraper and complaining that the elevators
took so long to arrive to pick them up. He advised to pla-
ce mirrors between the elevators doors so they would be dis-
tracted by their appearance and the complains disappeared <g>.
<snipped about Foxpro>
I know that TPS is quicker and better and ...
but I do not want to spent time and energy now
(having little left to do this now) if I do not need to
on a change of database-drivers etc. etc. I am the
first to recognize that the real beauty of Clarion is the
ability to almost effortless switch database-engines later.
> I can see you don;'t want to be the tail on the dog for very long.
> Part of that is being better. You don't get ahead by being "no worse
> than someone else". Given the age of this application I can't see how
> you couldn't really make something very nice with modern tools that
> does things that changes the way they do business in a big way.
> Companies will pay for that type of improvement. You need to show them
> something even small then they will pay. You don't really need to
> start out being as bad as the old program first before you do
> something smarter.
<g> I have an almost 35 year reputation (at this customer)
of taking the routes that stand out and making me better than
anyone else (that is why the long relationships with them). This
application was build for a group of companies in the same trade
by someone else (the group of course did not want the computer ex-
pert of one of them to look into their organisation also, so they hired a
new party to do that) though and it mostly worked (still does) well for them.
But we agree: they need to move to another platform to be
able to transition into the modern world and connect their work-
flow and communication with all parties into digital communcations.
So the smarter forms are on their way, but I need time to do it step-by-step.
That put me on the subject of priorisation. Working on it.
--
regards from Leeuwarden
Peter van Dobben de Bruijn
----
reply2usenet-2005 .at. The-Net-4U.com (.at. becomes @)
----
| |
| M.P. van Dobben de Bruijn 2006-06-29, 7:55 am |
| On Fri, 23 Jun 2006 22:09:20 UTC, "uds0" <uds0@juno.com> wrote:
> I wrote a fancy feedback version using progress bars which shows
> (rough) remaining time to complete and allows pausing/aborting for file
> rebuilding which is command line driven (could be from batch file).
> Rebuilding files is best done outside your app to reduce chances that
> the files are in use. You simply put in your file structure and
> compile, once per file structure
> It supports build/pack and auto-backup. Let me know if you want the
> source.
That would be GREAT ....
Allowing me to spend time on the move to TPS i.e.
|
|
|
|
|