Vendor names to Item table

Kisu

The item table gets Vendor No.'s from Vendor table, but how could I get the Vendor Names to the Item table also?

I added line to Item table for Vendor name and put table relation to vendor, what else I'd need?

If its possible I'd add the vendor names to the Item Card and List.

ufuk

You can use flowfield(lookup to vendor table where the vendor no in item table = no in vendor table.) or you can get the vendor name on OnValidate of Vendor No. field in item table like:

IF Vend.GET(Item."Vendor No.") THEN
Item."Vendor No." := Vend.Name;

bbrown

Don't put the vendor name in the item table. (violation of normal form rules).

Place a function on the item table that returns the vendor's name. Place a textbox on the itme card that displays the result of the function.

GetVendorName(VendNo : Code(20))

IF NOT Vendor.GET(VendNo) THEN
Vendor.INIT;
EXIT(Vendor.Name);

tinoruijs

bbrown wrote:

Don't put the vendor name in the item table. (violation of normal form rules).

Unless you want to be able to search or filter items on the vendor name.

bbrown

tinoruijs wrote:

bbrown wrote:

Don't put the vendor name in the item table. (violation of normal form rules).

Unless you want to be able to search or filter items on the vendor name.

You would do the search on Vendor No. not name.


Navision's continued ISAM mentality encourages bad programming practices.

bbrown

tinoruijs wrote:

bbrown wrote:

Don't put the vendor name in the item table. (violation of normal form rules).

Unless you want to be able to search or filter items on the vendor name.

If you really want to filter on NAME it would not be difficult to create a function that accepted a NAME filter and translated it to a Vendor No. filter to pass to the item table.

But I question the idea of basing a filter on a field that is not indexed.

Kisu

So which one would be better? There are about 1500+ items and they'd like to sort the items with the _vendor's name_ like they had earlydays with old program.

Not nessaserily need to be on the card but on the list. The vendor number tells something but its kinda frustrating to remember a numer that vendor has, thats why the name field.

ufuk

Use normal field, insert after Vendor No validation. Adding it to your table have no bad effect. Your table is very small.

bbrown

ufuk wrote:

Use normal field, insert after Vendor No validation. Adding it to your table have no bad effect. Your table is very small.

What happens when someone edits the Name on the vendor card?

ufuk

If using vendor name is important then I think putting a simple relation to Item table is not so difficult.

tinoruijs

bbrown wrote:

tinoruijs wrote:

bbrown wrote:

Don't put the vendor name in the item table. (violation of normal form rules).

Unless you want to be able to search or filter items on the vendor name.

You would do the search on Vendor No. not name.

I know it's better to filter the items on Vendor No. and use the lookup (Vendor List) to search on Vendor Name.
But I also know a couple of clients that won't settle for that and defenitely want the Vendor Name directly in the Item table.
"I don't want to click so much!"

Like Ufuk said; Use normal field, insert after Vendor No validation.

And put a function in the field Name (OnValidate-trigger) in the Vendor table that changes Vendor Name in all related Item-records.

bbrown

tinoruijs wrote:

bbrown wrote:

tinoruijs wrote:

bbrown wrote:

Don't put the vendor name in the item table. (violation of normal form rules).

Unless you want to be able to search or filter items on the vendor name.

You would do the search on Vendor No. not name.

I know it's better to filter the items on Vendor No. and use the lookup (Vendor List) to search on Vendor Name.
But I also know a couple of clients that won't settle for that and defenitely want the Vendor Name directly in the Item table.
"I don't want to click so much!"

Like Ufuk said; Use normal field, insert after Vendor No validation.

And put a function in the field Name (OnValidate-trigger) in the Vendor table that changes Vendor Name in all related Item-records.

Does your auto mechanic let you tell him how to fix your car?

idiot

bbrown wrote:

You would do the search on Vendor No. not name.


Navision's continued ISAM mentality encourages bad programming practices.

Navision itself is already an orgy of bad programming.

bbrown

idiot wrote:

bbrown wrote:

You would do the search on Vendor No. not name.


Navision's continued ISAM mentality encourages bad programming practices.

Navision itself is already an orgy of bad programming.

But are we obligated to continue the trend?

idiot

bbrown wrote:

Does your auto mechanic let you tell him how to fix your car?

Oh yes he does.
He even ask me what parts to fix & seeks my opinion on what brand to use while advising on the pros & cons of each brand.

idiot

bbrown wrote:

But are we obligated to continue the trend?

Are you obliged to make your client happy?
Are you obliged to make your client's life easier?
Suppose your client wants a report based on the Item table, which would have been easier to create, a report based on one table or a few tables?

bbrown

idiot wrote:

bbrown wrote:

Does your auto mechanic let you tell him how to fix your car?

Oh yes he does.
He even ask me what parts to fix & seeks my opinion on what brand to use while advising on the pros & cons of each brand.

Ok, maybe he does. Also maybe you are better informed then his typical customer. But does he not use his expertise to guide you to the correct decision?

bbrown

idiot wrote:

bbrown wrote:

But are we obligated to continue the trend?

Are you obliged to make your client happy?
Are you obliged to make your client's life easier?
Suppose your client wants a report based on the Item table, which would have been easier to create, a report based on one table or a few tables?

Yes, your goal is to make the customer happy by doing things right. Part of the task may involve educating the customer as to the right solution.

What is so hard about reports with multiple tables? These are relational databases after all.

idiot

bbrown wrote:

idiot wrote:

bbrown wrote:

But are we obligated to continue the trend?

Are you obliged to make your client happy?
Are you obliged to make your client's life easier?
Suppose your client wants a report based on the Item table, which would have been easier to create, a report based on one table or a few tables?

Yes, your goal is to make the customer happy by doing things right. Part of the task may involve educating the customer as to the right solution.

What is so hard about reports with multiple tables? These are relational databases after all.

Obviously we're living in different parts of the world so this will be my final opinion on this thread.

1. Not all customers are technically inclined. Some are not even computer savvy.
2. Customers always wish to minimize the work they do (number of clicks). Anytime something extra comes up it's a step back for them.
3. Doing the right things most of the time does not make the customer happy especially when the customer's desire is otherwise.
4. Doing things right <> doing the right things. "Right" is relative & relational.
5. Education = costs + time. Not all can afford
6. Expandability of the design chosen is another consideration

bbrown

This is just a discussion between professionals. Nothing personal here. We may be far apart but I think we see some of the same issues. Customers want everything but want to pay for nothing.

1. Not all customers are technically inclined. Some are not even computer savvy.

Some are, some aren't. Some think they are. The worst ones are those with "a close friend that is good with computers". Explain your solution in terms they will understand.

2. Customers always wish to minimize the work they do (number of clicks). Anytime something extra comes up it's a step back for them.

Like I said, the customer gets to decide what it will look like. If they want to click 1 button instead of 3 then it is your job to design the solution to meet that requirement.

That being said, if the customer wants a field on the Item card there is nothing in that request that requires it to be in the item table. Let good design and programming practices drive your solutions. Let the customer needs drive the user inteface.

3. Doing the right things most of the time does not make the customer happy especially when the customer's desire is otherwise.

Educate the customer. I would rather a customer say no to a $10,000 solution then to implement the $2000 solution they want, knowing full well we will give a way the rest of it later. The customer never remembers it was their idea. They just say "why didn't you tell me"?


4. Doing things right <> doing the right things. "Right" is relative & relational.

There is also a difference between "cost" and "price"

5. Education = costs + time. Not all can afford

Value?

6. Expandability of the design chosen is another consideration

Always. a design that follows a good structure will be expandable.