1 of 1 people found this helpful
there are expressions for &COMMONDIR and &GOLDDIR that are available in some situations, but I don't think they're available to the record type expression/rule.
You might work around it by simply creating a user-defined field like UDATABASE for use in your rules. Fill it in with an appropriate value for every contact in each database. You could even keep it properly populated via some SQL trickery or a lookup.ini.
Doug, I setup a Record Type as you suggested to Tim - urectype - and setup the rules to follow the "field value based". For Contact Set "A", I updated the values in all the records to "RecTypeA", in urectype; In Contact Set "B", I updated the values in all the records in the urectype field to "RecTypeB". When I switch between the datasets, the Primary Fields don't always change to the correct record type view even though the urectype field reflects the correct Record Type.
They are in v2017.1.0.377. Not sure what I'm doing wrong, but it seems no matter what I do/change, it doesn't help. Any thoughts as to what I could be missing?
Do they have duplicate contact2 records plaguing their database? It's more common than you think.
Check with this query:
select accountno, count(accountno) CNT from contact2 group by accountno having count(accountno)>1
If so, maybe the rectype thing is failing on contact who have dupe c2s... ?
Tim, Lois, I'd always done it with a custom field filled in with the name of the screen we'd wanted to display. Are you certain you want to have multiple databases for this?
We use extensive record typing and I would agree with Steck in asking why you need two databases? You can use the various security features including groups, record curtaining and field properties to effectively suppress records from either group.
We have more than 1 GM DB and it's working great for us with custom screens and record types! This may not be the norm but it works for us for what and how we want to use GM. Security is easier for us here too. Just my .02 worth tho...
I fully support your approach if that works for you. My reply was based on finding an answer to your initial question. I've used multiple Goldmine databases in the past 22 years but eventually reverted back to one because Goldmine's tools improved. If you find a solution to your quandary I'd be interested in reading the solution. Good luck.
Thank you all for your input. In answer to your question, Steck and Tim, long story short they have a unique business that requires separate datasets for various reasons. They have 2 major customer accounts and soon adding a 3rd. Each of these customer accounts require different APs, Lookups, user access, etc., but sharing most fields and they have over 400 custom fields which require different values in the Lookup table for each most of some of those fields.
Anyway, one database makes a lot of sense and I'm going to work on that with them. In the meantime, I'm restricting each dataset to specific users so for right now that is working to apply the correct primary field view for each dataset.
HOWEVER, all of a sudden, when I try to clone a primary view for this 3rd Record Type, I'm getting the message "This name is already in use. Please enter a unique name for this Primary Fields view." No matter what I enter, even if I enter the name of Test, I get this message. I didn't have that issue when I created the 2nd Record Type. I looked in the Fields5 table to see if there were duplicate rectypes for either of the existing two rectypes, but there were not.
If any of you have encountered this, let me know, at your convenience. I am going to call FR support this morning, so if I get a solution from them, I'll post it.
Thank you all again for your help!
Lois, as you know Tim's database dates back to the Goldmine 2.5 era, and sometimes the leftover cruft from older GoldMine can interfere with how certain features of GMPE behave / don't behave. (Like, for example, a MERGECODES in Contact2 that isn't used anymore.)
Maybe try the troubleshooting you'd do on a GMPE 2017 Connect that isn't working, maybe that'll clear up the trouble you and Tim are having.
Good thought, Doug, I will check that. See my reply to the original post. Just received an update from GM Support
Thank you all again for your input - I really appreciate it!
I just got off the phone with Brian @ GM tech support and he told me that there is now a known issue in 2017.1 (dated 6/8), where cloning a Record Type or Record Type View throws the error I mentioned above. The gen release of 2017 is ok. The issue was just acknowledged on 6/20 and there is an RM for it. However, there is no movement on the issue and it's in the hands of the developers.
So, just an FYI if any of you are going to be updating customers with record types or yourselves - stay on the May release of 2017.
Thanks again for all your help!