Master file attributes issue

[robert fuschetto]

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?

[David Beagan]

Could you have a second version of mf lurking in another folder?

Create a fex in App Studio:

WHENCE MF MASTER

MF is whatever your master file name is.

When run the fex, do you see the path to the file that you expect?

[robert fuschetto]

WHENCE fin_lvpg_fy_gl_vw MASTER

 

only see one....

[David Beagan]

You will never see more than one. Do you see the path to the file that you expect?

[robert fuschetto]

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!

[robert fuschetto]

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!

[David Beagan]

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.

[robert fuschetto]

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.