In a form or at a field setting

[Penny]

I am a newbie - not a database person but want to be. I am "attempting" to recreate a A4V7 database into A5V9. I did not create A4V7 database - that person is no longer with us (he created this back in 1998). Having found that only the tables can be salvaged for the new version, and I found I need to post one question at a time...my question is this:
How do you know/decide at what level something is to be done? Case in point...I want to default the value A into a record for a particular field at new data input. I see (and tried and it gave me an error) to put a default "a" into the field default. My next thought is maybe it should not be at the field properties but in an expression on a form???!!!??? Not sure which is correct, if either.

[Stan Mathews]

Re: In a form or at a field setting

I see (and tried and it gave me an error) to put a default "a" into the field default.

My screenshot shows one way to default a field (named sometxt) value to "A".

Since you don't indicate what you tried or what error you received, this is the best I can do.

[MikeC]

Re: In a form or at a field setting

Just to shed a bit more light hopefully--and is difficult, as Stan alluded to, as not much info is given....

Stan is using the field rules for the field--this can place a default into the field no matter where in your database it occurs---every form or browse that has this field will be affected.

If only an individual form/browse field is wanted to have a default, then do this on a form/browse event.

Conditions can also be placed to have the default occur only when wanted....or all the time.

So many ways and methods that, without many more details, it is very hard to give specific ideas to you.

[Penny]

Re: In a form or at a field setting

Sorry so brief- I gave too much info once,now shy.
Some background-hubby's company is a cold storage facility (very small, in very small town - currently not doing well financially so I am attempting to do this project). He has 1 person in the office, 2 working on the fork lifts (small samll company he put all his retirement money into it to purchase). Now he had to come out of retirement to try keep it afloat and is back driving a semi truck for a company.
Back to the database: old input form had some text that just automatically dropped into the boxes. That is what I am attempting to recreate. I have not gotten the form stage with the new version yet...trying to get everything right for the field properties etc. KNOWING, however, that later when the product ships out of the building - and she brings up the shipped form up (currently) - as she enters "thru" the text boxes it (the form I assume) takes the information OUT of the Lothead table and moves to the lotship table. The particular box that I have set up the default "A" for active is suppose to automatically change then the A to a "C" for closed (so when the report is pulled that shippped (and all others before it) will not appear in the report.

[Penny]

Re: In a form or at a field setting

Sorry so brief- I gave too much info once,now shy.
Some background-hubby's company is a cold storage facility (very small, in very small town - currently not doing well financially so I am attempting to do this project). He has 1 person in the office, 2 working on the fork lifts (small samll company he put all his retirement money into it to purchase). Now he had to come out of retirement to try keep it afloat and is back driving a semi truck for a company.
Back to the database: old input form had some text that just automatically dropped into the boxes. That is what I am attempting to recreate. I have not gotten the form stage with the new version yet...trying to get everything right for the field properties etc. KNOWING, however, that later when the product ships out of the building - and she brings up the shipped form up (currently) - as she enters "thru" the text boxes it (the form I assume) takes the information OUT of the Lothead table and moves to the lotship table. The particular box that I have set up the default "A" for active is suppose to automatically change then the A to a "C" for closed (so when the report is pulled that shippped (and all others before it) will not appear in the report.

[Stan Mathews]

Re: In a form or at a field setting

Not sure about A4V7 but with all the windows based versions of Alpha Five, you are working with event driven programming.

Can we assume that you now have the field defaulting to "A"? If so I believe you are now saying that you want the "A" to be replaced with "C" when the item is shipped. We have to find an event that happens when the product is shipped and tie the "A" to "C" change to that event. It seems likely that the end user performs some task to note that this has happened.

If we can discover that task we can proceed.

[Penny]

Re: In a form or at a field setting

Thank you for all your help. I did already set that default field to A and yes there will be an event created to make that happen (once I get to that step). I am not at that step yet - merely wanted to mention that later this field info changes and did not want the field default to be a problem when I get to that step.

Knowing which step when is my problem. I know the big picture but not how to make ALL the piece work. What I am finding myself doing is attempting to make a solution to a problem that I have not even encountered yet (wanting to nip it in the bud so that it will not be).

[CALocklin]

Re: In a form or at a field setting

Sorry so brief- I gave too much info once,now shy.

In my experience, you can't win this one. If you write too much, somebody (a) doesn't read it carefully and answers the wrong question or (b) complains about too much info. If you don't write enough, more info is requested. I have never found the "happy medium" and I don't think it exists. Let me know if you figure it out.

Here's a basic answer to your original question, "How do you know/decide at what level something is to be done?" If the default value will ALWAYS apply, it's probably best to put it in the field rules. My general philosophy on this is: If it can be put in the field rules, put it there - that way I don't have to worry about forgetting it when I create a new form later on*. If putting it in the field rules will cause problems somewhere, then it will have to be done in the forms.

*You said you are "not a database person" so here's a couple hints:

- You WILL be creating new forms, reports, etc. long after the application is first "done". Keep that in mind when considering table structure, field rules, writing scripts (Action Script or Xbasic), etc. You'll never think of everything but do your best to plan for the future.

- The things you think will be easy won't be and the things you think will be difficult won't be. For some reason, most people who are just starting out with databases seem to thing that the hard things are easy and the easy things will be hard. I once had a customer who was very apologetic about asking me to do something that he figured would probably take some time and effort but - could I please move a button from the lower left corner to the lower right. Another customer, to keep it short, felt that he should not pay more than $500 max - $250 was more realistic in his mind - for a job that really should have been at least a $5,000 job.

- Finally, read up on "normalization". There are something like 5 levels but only worry about the first 3. This will help you to set up your table/set structure in a more efficient manner and make it easier to do those updates I mentioned in my first comment. Here is one good link and you can find many others by searching on "database normalization": http://stat18.stat.auckland.ac.nz/st...Shed/norm.html

What I am finding myself doing is attempting to make a solution to a problem that I have not even encountered yet (wanting to nip it in the bud so that it will not be).

Good move!

[Penny]

Re: In a form or at a field setting

Am I wrong in my thought, however, that what was already developed/created for our company in Alpha4V7 for the total database....
am I wrong in my thought to totally recreate precisely what he had (all the menus, tables, fields in each table, expressions..yadda yadda)?

Abviously it was working (the program...it is the computer that is causing the hub bub). I want the company database to be windows based....and I want to know how to make it that way (just, can it be done in time before the old computer gives out)?

[Penny]

Re: In a form or at a field setting

ok, here comes my ignorance....(I am thinking my "thinker" is not correct) warning danger.....ignorance alert (Danger Will Robinson)

I am thinking that when I link/map/relate a table to another, just by the mere "link" I am joining the two tables are they were one.

YET, after reading the database normalization - I fear that I have "not" understood the concept. Am I now to believe the "link/map/relationship" takes the PLACE of the field rather than link all fields of both tables.

[CALocklin]

Re: In a form or at a field setting

ok, here comes my ignorance....(I am thinking my "thinker" is not correct) warning danger.....ignorance alert (Danger Will Robinson)

I am thinking that when I link/map/relate a table to another, just by the mere "link" I am joining the two tables are they were one.

YET, after reading the database normalization - I fear that I have "not" understood the concept. Am I now to believe the "link/map/relationship" takes the PLACE of the field rather than link all fields of both tables.

Sorry my comments may have been misleading. I'd forgotten that you were converting an existing A4 application.

Sounds to me like you are over-thinking it and were correct in the first place. When you link one table to another (create a set), it simply links them together based on one common field (sometimes more but let's not go there quite yet) and all the fields from the child table(s) become available to the parent pretty much as though they were part of the parent.

You shouldn't have to change anything regarding the structure in the original tables. You will have to recreate the sets but you can use the same linking values as were used in the A4 application. (Careful - "database" in A4 generally referred to one table. In A5, a "database" includes all tables and sets and, in my opinion, code, etc. - in short, everything for one application.)

Perhaps some of the confusion is in the fact that the text shows how to split out the duplicated data. This results in more tables but less redundancy. If there is a lot of redundancy in your existing application, you have two basic choices: (1) just use things the way they are and get it working in A5 or (2) do some restructuring to make things work more efficiently and make it easier to update things later - this will take longer initially but may help in the long run. You'll have to make that decision based on how well the current app meets your needs, what issues you've seen with it, and how much time you have to get it working.

One warning about normalizing - sometimes you need to be "redundant". One trap people often fall into is something like linking prices in invoices to the price in the "Prices" table. This is not a good thing unless you are certain that you will never, ever raise prices. If the price in the invoice is linked to the Prices table, every time you change the price in the Prices table all the old invoice prices will also change - not generally a good thing. So, when normalizing, think about what you are doing and make sure that changes to one table really should be reflected in all references to that piece of data or use a lookup to store the current value instead.

[Penny]

Re: In a form or at a field setting

Thanks for all your help. It is greatly appreciated. I have SO much that I have to do for this little bitty project (and even more for this "thinker").