Jump to content
The ibi Community has moved to a new platform: Please Sign In and choose Forgot Password to continue

Master file attributes issue


robert fuschetto

Recommended Posts

Recently a number of views were changed by our IT group. We deleted and recreated master files. They went without incident. We then went in and readjusted usage on certain columns. Again, no issues. However, one master file is giving us trouble in App studio. Let's call it: mf. It recreated fine. We updated the usage fine. FYI = A column came across as Actual format = P3 and Usage = P5. We went to the metadata editor, changed it's usage = I11. We changed a few others as well. We saved changes.

We go into App Studio and try to do a report...we hover over mf.column and the affected column STILL says P5! It did not change to I11 in App Studio. Again if we view the mf on the portal is says I11. We did the same exact thing in 4 other tables..all worked fine. We have deleted and recreated this mf numerous times to no avail. We recreated the master file one last time and this time suffixed with: _NEW....low and behold when do a new App Studio report using mf_NEW...the change are there--It says usage =I11! Of course all our code is references: mf no:t mf_new!

Somehow it seems this one mf 's usage is stuck on P5 in App Studio even though we have changed it on the portal, and it shows I11 there.

I.T. killed agents, restarted services and rebooted the server....all to no avail.

What the heck is going on with this one mf?

Link to comment
Share on other sites

THANK YOU! We appreciate the help!

It was inadvertently created in the wrong folder. Then all the craziness started after we created in the right folder. It was weird because some of the attributes came from the one folder and some from another. In the end it was a mess. All better now. This feels like a bug to me.

THANKS again!

Link to comment
Share on other sites

Dave, another question. T1.FiscalYear oriiginally came across as actual I4 and usage I11. This Joined well to our calendar table which was the same.

The new t1.FiscalYear comes across as actual: D8 and usage: D20.2.

The Join Failed.

We adjusted the usage on the new T1.FiscalYear to be: I11.

Our fex still failed and said Actual and Usage must be the same on columns joined.

We altered the actual on T1.Fiscal Year to be I4.

Now it runs.

What is the danger in what we did!

Link to comment
Share on other sites

There is danger in messing with these master file attributes.

You say it now runs, but is it correct? Will it continue to be correct going into the future?

It seems to me that it would be best to define the souce table or view with the same data type for FiscalYear as it was originally. And then recreate the metadata.

Link to comment
Share on other sites

I suspected so. The error thrown about column name and both the actual and usage needing to be the same for join or match was an eye opener. We always though it was just the usage. I suspect we 'lucked out'. We will need to do an analysis of the common fields we match / join on and see where the actuals changed I guess.....then either alter code with DEFINES or, if I understand you, get this IS dept to change the column type in the view....not sure how likely that will be.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
  • Create New...