Well said. That is a lesson I have had to learn also - it pays to be a little more careful when defining columns with the thought of the end processes that table will have to be involved with.
| "Jan Johansen"
<[EMAIL PROTECTED]>
Sent by: [email protected] 05/04/2005 11:56 AM
|
|
Group,
Not to toot my own horn but perhaps serve as a lesson/reminder.
I finally had to time to go back and look at a form that 'stopped' working.
There have been several times in the past where forms acted weird after an
update and it usually had something to do with the Dream Team working so
fast on fixes and minor differences in PROPERTY syntax happened.
Razzak will just give you that look when you say his engine quit working :)
so I knew it had to be something on my end.
This form had a DB-grid to display open or paid invoices depending on the
status of a Bit Button. This DB-grid was based on a view that had a WHERE
based on a pre-defined variable.
I couldn't figure out when this form quit working. Then I realized that I
had a computer with build 67 on it. The form worked in that build. Why not
now?
This form also had a bunch of tabs to display different areas of customers
concerns; contacts and such. The DB-grid for contacts worked, why not the
one for invoices?
Then I remembered that if you have too many relationships (read common
columns) that sometimes you dont see something.
Sure enough in my database creation I created my own problem.
Table Column
Customer CustPO
WorkOrder CustPO
Invoice CustPO
Although each of these tables needed to have the same PO number, they did
not need to be named the same. Changing names
solved the problem.
Just a reminder in your database creation that if you type in a column name
and it gives you a definintion (Text 20) then you have used this name before
and you really need to check yourself and ask yourself "What am I doing
right now?"
Jan
