Changing history

[Ian Copestake]

I'm a new user of build 266 on W2000 Pro.
Using the supplied Invoice database, while composing an invoice, if you change say the company name attached to a customer it seems the customer database itself is changed (rather than just this invoice).
All previously existing invoices will also change.
How can this be right?
Would this happen if you changed a lookup product price, i.e. would previous invoice totals all change?

Having just forked out the money, I am worried by the apparent lack of documentation on questions like this, combined with no free technical support.

[Jim Chapman]

RE: Changing history

Hello Ian,

>>if you change say the company name attached to a customer it seems the customer database itself is changed (rather than just this invoice).
All previously existing invoices will also change.
How can this be right?

[Ian Copestake]

RE: Changing history

Thanks.
So a looked-up value will never change later?
At least there is a choice then.
I would never use the other method for invoicing!

I'm now trying to figure out how embedded browses work. The provided help is very thin.
In their invoice database, I cannot see at the moment how the retail price in Invoice-Items defaults to a value in the Products table, yet can be changed for an individual invoice.

[Jim Chapman]

RE: Changing history

Hello Ian,


>>So a looked-up value will never change later? >, I cannot see at the moment how the retail price in Invoice-Items defaults to a value in the Products table, yet can be changed for an individual invoice

[CraigSchumacker]

RE: Changing history



""Having just forked out the money, I am worried by the apparent
lack of documentation on questions like this, combined with no free technical
support.""
Ian:
I'm probably wrong here, but in reading your post, I almost get the feeling
you purchased Alpha Five to use it's invoicing application.
The invoicing application, at least in my mind, is a sample application
included with A5 to illustrate a few A5 features, and to illustrate how one
might set up the menu system around an application.
The author of the sample application probably created it based on his
experience with some specific business he worked for (or owned) in the
past. While it undoubtedly would work quite well in that place of
business, I have no doubt that a few (if not many) enhancements would be
required before it could be used effectively at another place of business.
Even the most generic invoicing applications, like Quickbooks, can be used in
any business, but they never quite fit the mold.
The purpose of Alpha Five is that it empowers the user to create a custom
application around a specific bussiness' needs. It is for this very reason
that application development software exists.
O.K., my long winded point...
Instead of looking at what the sample app does do, I think you'll need to
look at what it doesn't do, then addressing how to go about changing it.
This is tricky for a new user, but achieveable.
First, you need to print the manuals that come as a word document.
Unfortuneatly, most software companies have ceased supplying printed
documentation, and Alpha Software is one of them.
I can't imagine customizing or creating applications without my printed
manuals at my side. Trying to research information from the Acrobat files,
in my opinion, is a time consuming task at best. At this point, I am very
familiar with both the XBasic manual and the user's guide, so much so that I can
(almost) go directly to the page to review or refresh my memory on any topic.
Yes, it takes a lot to print them, but once printed, a whole new realm of
potential is released! Perhaps you could print a chapter a night, or
something!
Second, invest in Peter Wayne's books. He has two, one devoted to using
A5, and one directed toward the XBasic language. They are more user
friendly than the A5 documentation, but are geared toward examples, rather than
detailed and complete instruction.
Now, if you are looking to modify the sample application, make a "clean"backup
copy of it so you can go back to it's original state, then, with books in hand,
start dissecting the application. Find out how things work, what you want
to change, and create the ultimate application for you purposes!
Be sure to see the tips section on the Alpha software site, and familiarize
yourself with Peter Wayne's website, www.learn alpha.com.
This bulletin board has a great search capability, tons of users commited to
helping each other, and is a fantastic resource.
There is also an older bulletin board that has been archived by user Doug
Chanley, and it, too, has great search capabilities. It is located at
http:64.225.54.8alpha_message_board_archive .
Welcome aboard, dig in, and enjoy. A whole new world of creativity and
ability awaits you!
Craig

[Ian Copestake]

RE: Changing history

>>So a looked-up value will never change later?

[Ian Copestake]

RE: Changing history

Thanks for your helpful encouragement.
I didn't buy it for the invoicing package, but was just looking at that as an example.

I don't seem to have Word documents, but have already printed the Acrobat User Guide - I presume this is the same.

I have not started on xbasic, but was fairly amazed when I managed to cut and paste a script from the invoicing app, change a couple of names, and print my own form in a report layout!

I will certainly look at the Peter Wayne site, which I didn't know about until your reply.

Thanks again. It is reassuring to have such prompt responses to the queries of an ignorant newcomer.

Ian.

[Peter.Greulich]

RE: Changing history

Let me throw my 2 cents in. Alpha is a very powerful database. It offers tremendous flexibility. Ver. 5, when it is released, will be an order of magnitude greater in power and almost unlimited capabilities, far above and beyond Ver. 4.5/266.

[Tom Cone Jr]

RE: Changing history

Ian,

>> I cannot see at the moment how the retail price in Invoice-Items defaults to a value in the Products table, yet can be changed for an individual invoice.

[whanigsberg]

RE: Changing history

>>I don't seem to have Word documents, but have already printed the Acrobat User Guide - I presume this is the same.

The documentation is on the CD in Doc and PDF format. The readme advises us to use the PDF for online reference and the Doc to print from.

Bill

[CALocklin]

RE: Changing history

It sounds to me like you need to be careful to distinguish between a "lookup" value, "linked" value, and "calculated" value.

A "lookup" is simply that, you lookup the value from some table (could even be the current one) and put that value, or a group of values, in the current field(s). I've added the plural here because you can do things like look up a customer and fill in the address, city, phones, etc. all based on one field rule. Plain lookups and filled in values can often be changed but that is determined by how the field rules are set up - there are lots of options.

In your original question, the Customer Name is actually a linked value. It's probably linked by way of the customer number. So, when you change the value on the invoice form, you are actually changing the name in the customer table - which is linked to every other invoice to show the 'appropriate' customer name. ('Appropriate' is in quotes because, as you suggest, changing it in one record could mean that it would become 'inappropriate' in other records.)

A calculated value could be calculated based on fields in the current record, fields in a different record, records in a different table(s), today's date, or even data extracted from a text file (requires Xbasic). I believe a calculated field will only update when the record is saved. (Normally, this means that some value in the record must be changed in order to update the calc field.) I know it used to be this way but I'm not absolutely certain about the latest version. I hope it hasn't changed and here's why: Some of my tables have a "last change" date field - this is a calculated field which is simply defined by the function DATE(). I've found that asking the user to update the 'last change' date manually is a waste of time so it must be done automatically. Obviously, if the calculated field changed every time I viewed the form or printed a report, then every record would appear to have been changed every day - not exactly what happens.

If you need a calculated value that updates every time you view a form or print a report, consider putting a calculated object on the form/report. This is NOT a calculated field in the table it is a calculated field on the form. These will update every time a new record is fetched. In most cases like this, there really is no need to store the calculated value in the table because it is really only the result of other fields that already exist. So, rather than wasting hard drive space (although not really an issue any more), why not just store the 'fixed' values and display the calculated value when you need it by putting it only on the form, report, or other layout.

There are many methods/functions for creating lookups and calculated values so I won't even try to list them here.