home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Archive Magazine 1995
/
ARCHIVE95.iso
/
discs
/
pipeline
/
3_10
/
Gaynor
/
LETTER
< prev
next >
Wrap
Text File
|
1990-03-25
|
4KB
|
110 lines
%OP%IWC
%OP%BON
%OP%IRY
%OP%PL68
%OP%TM1
%OP%HM0
%OP%FM0
%OP%BM1
%OP%LM6
%OP%RN100
%OP%RB0.001
%CO:A,65,65%%R% 7 Bedford Road
%R% Letchworth
%R% Herts.
%R%25/03/90
%L%Gerald Fitton
%L%c/o ABACUS Training,
%L%29 Oak Grove,
%L%Upper Stratton,
%L%Swindon
%L%Wilts.
Dear Gerald,
I am writing to you about a technique for using the linkimg
file that I use for my home accounts. If you are not already
aware of it you may find it interesting. The files I refer to
are on the enclosed disc. Below is some pre-amble to the way I
have set up my accounts. They may not be very sophisticated, but
they work for me. If you want to skip the pre-amble go straight
to the section headed LINKING FILE. By the way the values &
headings in the sample disc are totally ficticious!
%H2%HOME ACCOUNTS%H2%
When I had a Beeb I used Interbase to hold monthly transactions
and then posted summaries to Intersheet for my account summary.
I had one file on Intersheet for the year, but 12 files on
Interbase, a set of transactions for each month (actually it was
13 as I get paid 4 weekly, 13 times a year). The approach I used
with Pipedream therefore started from an attempt to keep to this
approach.
There is therefore one summary file (called BALANCES on the
disc). Then there is one file of transactions for each month.
These are created as required (just April & May on the sample
disc). I considered using external references, but that would
have meant having 13 worksheets on the screen at once. I doubted
I could handle that, never mind the memory usage. So instead I
used the linking file approach. This has the advantage that it
is updated permanently by changes to the transaction files.
Loading the summary file & recalculating draws the latest values
off the link file. I only need the transaction file I am working
on loaded.
%H2%LINKING FILES
The problem with linking files was that the normal slot
reference could not be used. Column A had to be referenced as 1,
column B as 2 etc. At first sight this seemed to mean that
relative values could not be used. This would mean that entries
could not be replicated, and every entry would have be input
slot by slot - a lot of work on the balance file for say 238
slots (17 rows by 14 columns). It would also be very inflexible
as changes (say increasing the number of rows) would be a major
task.
However as you will see I found a way round this and the whole
system seems to work quite neatly. Basically the idea is to set
up a row containing the x values for the linking file (row 32 on
the BALANCES file), and a column containing the y values (col Q
on the BALANCES file).
%P0%
%L%These can then be referenced and evaluated in the main body of
the file - for example slot C5. Slot C5 can then be replicated
to fill the block C5 O21, where each slot will reference the
appropriate link file address. I'm not sure I have explained
this very well but I think it is easier to follow from the
actual file on the disc. I hope the explanation is not too
brief, but I have tried to keep it a short as possible. I'm sure
you are swamped with letters.
The transaction files follow the same principle. With the
transaction file I have collected the totals for an account type
into a block at the start of the file. This is not strictly
necessary, but I think it's tidier.
%H2%OTHER POINTS
Finally I have set protection so that I can only update slots
that are meant to be amended manually.
Also recalculation should be set to manual for the transaction
files. Otherwise the linking file is updated as each
transaction is entered which is extremely irritating.
I hope you find this technique interesting if you are not
already aware of it. I enclose some stamps for the return of the
disc.
Yours Sincerely
Stephen Gaynor
%CO:B,51,44%%CO:C,44,44%%CO:D,12,0%%CO:E,12,12%%CO:F,12,0%