Conference iosg::all-in-1_v30

    Michael,
    
    With a personal name like yours, it's lucky that I'm talking to you on
    a VMS system at all :-)
    
    However...
    
    ACCOUNT.DAT doesn't seem to be a file that's part of the normal
    product, so I assume it's some customisation on your system.
    
    Further I assume that you are trying to find out how to define a
    DATATRIEVE domain (is that what they're called?) to map the file.
    
    If so, take CM option, someone will have to make you an application
    programmer to do this, then SEL the form that describes the file
    ACCOUNT.DAT, if you're lucky, the form will be called ACCOUNT, but it's
    reasonable for you to go and ask someone if it's not!
    
    Then take the option which is called CDD in V3.0, I can't remember if
    it was that in V2.4, which will make you a domain definition of the
    file.
    
    OK?
    
    Graham
    
    
    

	Michael,

	I made a slightly different assumption than Graham -- namely, that your
DATATRIEVE domain and record definition were already set up, and you just wanted
to use some DATATRIEVE commands or procedures to access the data.  In this case,
you can do all of that from within ALL-IN-1 by using the DTR function.  See the
ALL-IN-1 Programming Reference: Vol. 2 for more information on DTR.

	If your questions are more specific to the actual DATATRIEVE commands
you would use to write such a procedure, you would probably be better off
addressing that to the DATATRIEVE conference (even though there are certainly
many people in this conference who are capable of answering most of those
questions).

	Finally, I'm just curious...  if this is already an ALL-IN-1 data file,
and you (evidently) already have the ALL-IN-1 mechanisms (e.g., entry form) in
place to work with it, what is it that you need to do that you feel cannot be
done directly from within ALL-IN-1?  (I.e., why is someone suggesting 
DATATRIEVE?)  Maybe there's a more direct way to do what you need.

	F

    ACCOUNT.DAT is a data file containing a sub set of customers used for
    organising PM visits etc.  What is required is a method of extracting
    and printing subsets of this data.  For instance, all those with a
    numercal field between two values.  DTR was suggested only because I
    know something about it.  If there are such mechanisms within ALL-IN-1
    then this is probably a better route to take.  How should I gewt
    started?
    
    I have no domain information at all.  I only have this data file, entry
    form and a (very) crude index form.
    
    All help greatfully appreciated.
    
    
    Regards, Michael Williams.
    

	I'd suggest first the ALL-IN-1 Application Programming: Getting Started
manual.  Specifically, Chapter 10 discusses creating formatted output (i.e.,
reports) from ALL-IN-1 data.  What it basically amounts to is createing a
"template" of the report you wish to create, and then using various ALL-IN-1
functions to manipulate the data that goes into that report.  Examples might
include *what* data records to select for reporting, *which* parts (fields) of
the records to display, *how* to format the output, etc.

	F

    .4 is, of course, correct.  All the information you need is in the
    books.  Of course, all the words you need to write a novel are in the
    dictionary, too.

    I have hacked together a VERY CRUDE script that illustrates how simple
    it can be to obtain a fairly decent report from standard ALL-IN-1
    facilities.  I have created a script which finds all the entries in my
    personal telephone directory which start with area code (904).  

    To try it and to extend it you can extract the script from the next
    reply and invoke it.  You will also need to create a simple text file
    in your ALL-IN-1 directory called 904_CODES.HDR which can contain any
    (or no) text you wish as a header.  This would normally be done as a
    header in the MERGE function but I chose this way in an attempt to be a
    simple as possible.  A lot of people think I am far too simple but they
    I don't really care.  ;')

    You will need to add a couple of entries to your personal telephone
    directory which have home telephone numbers which begin with (904). 
    Mine is (904)326-2873, for instance.  Then invoke the script supplied
    via <DO 904_CODES.SCP (if that's what you named it).  I recommend using
    the PF VM menu to access the script as it's a very convenient menu for
    this sort of hackery.

    While you're on the DIR PER menu I suggest taking a look at the code
    which implements that simple but powerful menu.  I suspect it may come
    very close to something you could copy and hack to fit your needs.  The
    way to look at the code is to mash CTRL/N to view the Named Data, of
    course.

    The dataset is mapped by the PHPENT Entry form.  I am using the
    OA$BLP:PHPERF.BLP template as the report body.

    Armed with this small example and experiencing it should now prepare
    you to read the nice book and copy from the existing code.

    Keep the faith,
    don

! 904_CODES.SCP		Test printing a selected list of personal entries
!
!
! This is a REALLY SIMPLE and STUPID script to show how to create a special
! 'report' can be generated within ALL-IN-1.
!
! This will create a file called 904_CODES.TXT which contains a list of all
! the entries in the ALL-IN-1 Personal Phone directory which have (904) as
! the first part of the home telephone number.  This obviously silly and
! hardcoded but what do you want for nothing?
!

!		Delete any possible old report

	DELETE_FILE 904_CODES.TXT

!		Copy a 'header' file that says something useful

	COPY "904_CODES.HDR" "904_CODES.TXT"

!		Process through the personal phone directory for the desired
!		area code

	FOR PHPENT WITH .HOMEPH = "(904)" DO -
	 GET #USER = .USER\\ -
	 MERGE PHPERF.BLP, 904_CODES.TMP\\-
	 APPEND "904_CODES.TMP" "904_CODES.TXT"
!
! [End]

	While .6 certainly should work, and serves as a good example for small
amounts of data, you might also want to consider one other performance improve-
ment if you are generating reports from rather large amounts of data.

	The example in .6 will generate as many temporary files as it finds
records that match the selection criteria (i.e., in the FOR loop), and continue
to append these files together -- something that can get rather costly, in terms
of system usage.

	A better approach might be to move the FOR loop *inside* the template
itself.  This can be done by using the special <&OA...> syntax provided by
ALL-IN-1 templates and the MERGE function.  It is actually a quite simple
modification.  Using the previous example, for instance, you might create a
template that is invoked *once* (from the script, using the MERGE function);
then, in that template, you would have something like:

<&OA FOR PHPENT WITH .HOMEPH = "(904)" DO GET #USER = .USER\\ <->
GET OA$MERGE_LINE = (however you want to format your output line)>

	Again, you could add all sorts of extra formatting, etc.  But this
example would generate only one file, and continue to write to that file
throughout the FOR loop -- which could be significant, as I said, if you were
processing a rather lengthy report.

	F