Re: A Challenge?

In message <4dd89907f5Jeremy@xxxxxxxxxxxxxxxx>
Jeremy C B Nicoll <Jeremy@xxxxxxxxxxxxxxxx> wrote:

> In article <5a3a8d84d%beamendsltd@xxxxxxxxxxxxx>,
> beamendsltd <beamendsltd@xxxxxxxxxxxxx> wrote:
> > In message <4dd73248d0Jeremy@xxxxxxxxxxxxxxxx>
> > Jeremy C B Nicoll <Jeremy@xxxxxxxxxxxxxxxx> wrote:
>
> > > But I'm interested in what causes this speed problem. !Prophet
> > > runs on - what? RPCs? Is the slow disk interface, that's the
> > > bottleneck? Or the processor itself? What's !Prophet written in?
> > > If it's BASIC, has anyone ever tried compiling it?
> > >
>
> > It's the way a document is created - it's done in memory so disk times
> > are not the issue.
>
> I thought the major complaint was the start-up time for the system to
> "load" everything into memory.

No - the delay loading was a side issue related to network user
solution.

>
> > The process seems to be: It looks at every stock item to see if it is
> > the subject of a current uncompleted invoice, quote or credit note -
> > if so it flags these. It then creates a new new invoice, or if it has
> > found an unfinished invoice for that customer, re-creates the
> > unfinished one, again checking all stock items three times.
>
> > The ability to "remember" uncompleted docs is great, but it does mean
> > 6 passes through the 16,000 item stock database - each pass taking
> > rather longer than a straightforward search for, presumably, some
> > interesting programming reason.
>
> Beats me. Unless the code doing this is amazing simplistic it
> shouldn't take all that long. What I find more interesting is why it
> needs to do that at all... If the app is single-user then it could
> have:
>
> a) loaded the database at start-up
> b) scanned everything to generate a subsidiary index of "in-use-now"
> items
> c) made itself available to the user. From then on, anything the
> user wants to do could involve checking scans of only the
> subsidiary index, which would hopefully be instantaneous. If
> the user was creating a brand-new invoice then items added to
> that would get updated in the main database and also added to
> the subsidiary index. If the app/machine crashes then next
> time it starts it buidls a new subsidiary index from the updated
> database.

My comment was that it can be a bit frustrating loading a new
invice with a customer hovering at the counter, not loading
the whole thing.

>
>
> The only reason not to design the app with some sort of index/cache
> like this would be if the author had (a) a fast machine, and (b) no
> expectation of many items in the database. But the app is old so I
> don't see how users could be expected to have (a)... The thing is,
> though, that with a single-user only, there's no way that the state of
> any item in the database can change other than by the running
> application itself doing so... and so it can cache that change and be
> certain that the cache is accurate.

An item can be on an uncomplete trade counter invoice when a counter
customer comes in, so rather than scrap the trade counter invoice
!Prophet remembers it while the new invoice is dealt with. A very neat
feature.

>
> > With 1000 stock items there is barely any delay, but it seems to get
> > exponentialy slower as the database grows.
>
> Exponentially slower is bad. Linearly slower would have been better.
>

Richard

--
www.beamends-lrspares.co.uk sales@xxxxxxxxxxxxxxxxxxxxxxx
Running a business in a Microsoft free environment - it can be done
Powered by Risc-OS - you won't get a virus from us!!
Boycott the Yorkshire Dales - No Play, No Pay
.

Relevant Pages

  • Re: Date / Autonumber anomaly
    ... start a brand new database beginning with new invoice/record numbers. ... think the corruption may be due to the age and size of the database. ... corruption doesn't get carried forward because it exists in your invoice ... but the intent of Autonumber is to ...
    (comp.databases.ms-access)
  • Re: Date / Autonumber anomaly
    ... In that case, try creating a new, empty database and importing ... corruption doesn't get carried forward because it exists in your invoice ... entering, displaying, and editing the data. ... but the intent of Autonumber is to ...
    (comp.databases.ms-access)
  • Re: Split database continued
    ... The code for creating a one off invoice takes 12 seconds with the database ... Private Sub Create_New_Invoice_Click ... Dim Invs As DAO.Recordset ...
    (microsoft.public.access.formscoding)
  • Re: Date / Autonumber anomaly
    ... I suggest, for your sequential invoice number, that you use the DMAX domain ... aggregate function, to which you add one, rather than relying on Autonumber. ... Bob's correct -- database size is not a known cause of corruption. ...
    (comp.databases.ms-access)
  • Re: Problem with a template from the MS Office website
    ... noted and have resolve them and reposted them the updated db to our web. ... database. ... I suspect it will be ages before my Access and VBA ... and controls so that the Invoice Report ...
    (microsoft.public.access.reports)