Tough To Explain

[abomb]

Hi Everyone,

This is a hard problem to explain but I will do my best. I want to make a field not only reference another field, but also be conditional upon another field. Here's the situation:

Dept. A enters a Piece # and other info

Dept. B then references the info through piece number, makes piece, then marks

complete through a radio button.

This info then is referenced back to Dept. A as completed. Now when Dept. B looks for open jobs, all that is listed are the pieces marked "No". Hope it's not to complicated to understand.

[Slobey]

I may be confused about what you want. If the no is simply anything that is not marked as complete, then why do you need a new field. Simply perform a find on the radio button field. Are there other criterial for this find?

[LaRetta]

Hi abomb,

I highly suggest that you keep your pieces names apart from their Completion status. You need a Status field (text). I *think* you may have one (which your radio button is attached to?) but it's unclear.

Then you have 3 options. I suggest option 2.

Option 1) Have your Users click a button which performs a Find on Status = "No"

Option 2) Use a portal with your radio button above it. This allows you to display all Completed pieces -- or -- all Incomplete (No) pieces. HowTo: Create a global (text) field called gStatus. Create another table occurrence of your table (or file). Name this new occurrence 'Job Status.' Join gStatus to Status on =

Place gStatus on a layout and attach your radio value list to it. Create a portal based upon Job Status table occurrence. Place fields within it also based upon this new table occurrence. Click the 'no' radio. Incomplete jobs will display. But it allows seeing Completed pieces if needed.

Option 3) Same as above but it just always displays incomplete jobs in that portal. Instead of using a global field, use a calculation (text). All you will put in the calc box will be "No" ... include the quotes. Then use this field to join to your Status field. Then it will always simply display incomplete pieces without User intervention.

If you insist on combining the piece name with it's current status, just change the piece field (let's pretend it's called PIECE) definition to Auto-Enter with calc of:

PIECE & " - " & Status

Unclick on Auto-Enter tab right below calculation 'Do Not Replace...'. In this way, every time the status changes, the piece name will change. ie, if Piece is 1956 Corvette (smile), it will show: 1956 Corvette - No

But again ... I highly recommend keeping this data apart.

LaRetta

[abomb]

I'll try to explain this a little better without making it more complicated. Now, this way may not even be possible with FM. I'm trying to create a database for my company. Right now all of our departments are what we call "islands." We do have a system to put orders through, but it involves alot of paper and repeated entries of the same information. This step involves order entry to engineering. As of now, engineering will rewrite alot of the same information from the orders on our job cards. I am hoping to eliminate these job cards (again, may not be possible with FM but if nothing else to create a "rough draft" for some professional to create). Here's how I see it in my mind,

1. Order is entered with all main customer information drawn up from a customer lists table.

2. This entry screen assigns a unique job # to job.

3. A hard copy of all drawings and a copy of P.O. is given to engineering.

4. Engineering can then pull up order through the job #. Removing any double entry.

5. Engineering then drafts the pieces and assigns "piece #'s."

6. Production Departments then can access what they need via the "piece #." Then they can print out a small detail of only what is needed instead of a big paper job card being passed around.

7. I then wanted a place where they could mark complete. This would then let production know only the pieces that still need to be cut so there is no duplicate production. It would be nice to have production manager be able to click "yes" on that radio button and then have it removed from his drop down list of items still to produced.

My idea on how this could work was to create two radio buttons. One on Engineering and one on Production Page. When Production marked "Yes," have a lookup mark it "Yes" on Engineering. Then I tried to make the Job # List look for "piece #'s" conditional on that radio button being marked "Yes." That is it would only bring up the ones that are marked "No." I thought that radio buttons would be the easiest for people to use. Again, I'm still pretty new to FM and database thinking in general so it may not be possible to do how I want. I Hope I didn't make it even more confusing.

!Again, this is just how I would "like" it to be. Any other suggestions would be greatly appreciated.

Thank you very much for all your help

[LaRetta]

"One on Engineering and one on Production Page. When Production marked "Yes," have a lookup mark it "Yes" on Engineering."

Are Engineering and Production two different tables? Or files? Are they related? If so, how? Are you networked? Because, if they are related, you can use only ONE radio field. I call it cross-placing (there's probably other words for it).

A conditional value list (one which automatically removes Piece#'s with YES) is quite easy. But we need to understand your existing FM structure to make cohesive suggestions.

LaRetta

[abomb]

OK, I'll try this again. Thank you for your patience. I think I've decided to take a bit different direction.

First, I did have two different tables; one for engineering and one for burning. They were related by piece #.

Second, I think I found a better way. If you could check my logic. Instead of having some sort of conditional drop down list, I'll have radio boxes on the engineering page only. When a department finishes a piece or step, they would go into the engineering page to mark completed "yes" or "no". Now Each Department can just run a daily find report to list each open order. This would also allow our sales dept. to look on the status of a piece or job. The list will hopefully give him the info he needs or he can go reference the production steps through piece #. I think this makes keeping track easier for some of our less computer savay managers and my life easier in terms of getting the results I want.

Any more suggestions will be most welcome. I'll update as needed.

Thanks again for all the help.

[LaRetta]

That logic seems pretty clear.

" When a department finishes a piece or step, they would go into the engineering page to mark completed "yes" or "no"."

Since they are related on Piece#, my mention of cross-placing the field should work. In other words, department won't even have to go to engineering page to mark completed. Just place that Completed field (from engineering table) directly on your department page. Attach the same radio value list. If these two tables are related on Piece# and it is a one-to-one relationship, this will work well.

You might also review options with portals.

"or he can go reference the production steps through piece #. "

Your staff shouldn't need to go to other tables at all, ie, you can cross-place fields or use portals to provide them with all the veiws they wish right where they sit.

Have fun with your project!!

LaRetta

[abomb]

Hey LaRetta,

I don't quite understand "cross-placing" the field, again I am still pretty new. Does this mean that it would be a "copy." I definately would like production managers to only have to reference one page.

Can I cross place just radio for each engineering step onto specific production tables? (just trying to understand)So there would still be many radio's on my engineering table but only one on each production table with a one-to-one relationship for each. (This is what you mean right?) Again I would really like to have production reference only one page.

I like the idea of how you suggest to do it but I don't really understand portals and cross placing to really get what is going on. If you don't mind, could you dumb it down a little. Like I said, I understand the concept, but not how to actually do it.

Thanks again.

[LaRetta]

"Can I cross place just radio for each engineering step onto specific production tables?"

I'm unsure of your fields or structure. But try this:

Go to your Engineering page and CTRL-C to copy that Complete field radio button. Go back to your Department layout and CTRL-V to paste it. Just for this test, to be sure you are viewing the correct radio for the correct Piece#, copy and paste your Piece# or PieceName also (from engineering to department).

You will (probably) see that - since they are related on Piece#, the fields transfer fine.

What the department will be clicking IS the engineer's radio. They can make changes to the Piece item from their table. This is cross-placing.

LaRetta

[abomb]

That worked perfect! Thank you so much.

[LaRetta]

Ahhhhhhhh ... welcome to the rush. That is what one gets when the power of relational starts coming clear. This dynamic accessibility (without need to duplicate data) is what will get you hooked on this stuff. I know.

A few final comments, if I may?

You probably don't even need two tables. Usuaully, if there is 'one bit' of information (each separate field), that data would all be stored within one table - your Piece table. But I use one-to-one tables myself occasionally to keep the logic of groups of fields independent from other groups.

What I'm saying is that, since you have a one-on-one relationship between engineering and departments, you can place any fields on EITHER table. Your engineering can have department fields also and they each can make changes to the Piece information as needed (if you allow them to). If you only want engineering to view a Department field but not be able to change it, just right-click on the field > Field Behavior > and unclick Allow Entry in Browse & Find.

Now knowing this, I hope you don't have duplicate fields that you really don't need. Because if engineering changes data in a field, and departments doesn't make the same change in THEIR field, it will drive you nuts. Since both can access each other, duplicate fields are (usually) unnecessary.

And, instead of generating a report? I would place a portal list on Departments layout which only shows those Pieces incomplete. This running list would update instantly as engineering and departments changes the Status. And if the department manager wanted to review one of these incomplete pieces further, he could click the row and jump to it's detail. You will find your Users will adore you for these portals (and Sales can have the same portal on their view) and they are much easier to make than layout switches and find scripts. When you're ready ...

Have fun!

LaRetta