Vendor Combiner and third party products

(0) Share

Report

Posted on by Richard Wheeler

75,848 Moderator

I have a client trying to use the Vendor Combiner Modifier and they are getting a duplicate key violation on the GS1099 table. When I contacted Greenshades they had no idea why. My question is how does GP even know about the GS1099 table? There were no triggers that I could see. Is it possible that in the routine it looks for all tables that have the field VENDORID and builds its list from there?

*This post is locked for comments

I have the same question (0)

All responses (6)

Answers (1)

Verified answer

Ian Grieve 22,784 on at

Like (1)

Report

From testing I have done in the past, the Combiner tools do look for the column name in any of the Dexterity tables to update.

Was this reply helpful? Yes No
Richard Wheeler 75,848 Moderator on at

Like (0)

Report

Thanks, interesting because the error message is actually correct because the vendor record does already exist in the GS1099 table. Not sure why the combiner works properly on GP tables but not the GS tables.

Was this reply helpful? Yes No
Beat Bucher GP Gee... 28,058 Moderator on at

Like (0)

Report

Hi Richard,

I don't own or even ever worked with Greenshade, but my feeling is that their table might have a FK constrains that is based on the sole VENDORID field, or a combination of another field with this one, thus causing the key violation. Can you check the properties of the table ?

Was this reply helpful? Yes No
Richard Wheeler 75,848 Moderator on at

Like (0)

Report

When I had GS support on the line they had no idea. I will check the properties just for the heck of it. That is a good idea.

Was this reply helpful? Yes No
Chris.Hadden 726 on at

Like (0)

Report

Richard,

I'd be interested in reviewing this further with you and our team. Feel free to email me at chadden@greenshades.com and we can discuss this further.

Was this reply helpful? Yes No
Tim Wappat 5,711 on at

Like (0)

Report

Same issue as the customer combiner has, I documented it here:

http://timwappat.info/post/2015/09/03/Customer-combiner-and-table-not-found-errors

Basically the "combiners" iterate through the database looking for the column name and renames any values it finds in that column. This is why its important to stick to the original column names if writing add-ins.

The GP script knows about tables that use this column as a primary key in base product, but you have to handle 3rd party ones in the pre-scripts.

See the end of this post on naming objects and the combiner

http://timwappat.info/post/2015/09/02/Care-naming-database-objects-in-Dynamics-GP-for-custom-GP-Addins

The customer combiner principles are same for your problem.

Was this reply helpful? Yes No