Hello, Idea: I would like the Display Language to have more options in PBI Service/Fabric Preferences, including "English (UK)", "English (AUS)", or even "English (NZ)" so we can force dynamic date formats to conform to our local norm of dd/mm/yyy. --- I work for a Healthcare Service and getting dates in the format dd/mm/yyyy is imperative for operational reports especially when it relates to patients getting to appointments and bookings etc. There is a Swiss Cheese Safety problem here, that if a cancer patient were to not be correctly waitlisted or given an appointment as a result of someone not seeing the treat by date correctly, then the outcome could be potentially fatal. We do our best to block the holes in the Swiss cheese safety model, see examples below, but we would like to force the Display Language to a dd/mm/yyyy English format to eliminate the holes. Currently we rely on browser settings, however Edge Browser settings in our Org are maintained by our Infrastructure Team, and after each desktop update, we often have to request the Browser settings be updated. (1 hole we trying to clog) The problem often comes as a result of new staff performing such actions. I have done lots of training with Analysts to not use the (*Dynamic Date) which is the default field in PowerBI Desktop when developing a report. That way the date shows in the dd/mm/yyyy. But because the default date field is a dynamic date in most cases with setting up the dataset fields, it's hard for Analysts to always remember. (Another hole) We provide PBI Training to End Users, but again, user errors occur, and big organisations frequently have new staff starting each week. (Another hole) --- Summary: Basically, we don't want our patients to die over something as silly as default USA date formats. Especially when these language options exist in other Microsoft Products. Sincerely, The Rest of the World.
... View more
on:
UI for Editing Small Lakehouse Tables (Metadata & ...
on:
Power Automate visual in Power BI Desktop does not...
frithjof_v
on:
Job scheduler API: List failed runs
Thanks for the input.
Trying to understand the scenario better - what would be the reason for doing this?
Eventhouse data and OneLake Availability is considered as one logical copy with same access level and retention. You can query the data in OneLake without using the Eventhouse compute for historical analysis, while querying the Eventhouse direcely for timeseries/real-time analytics.
If you would like to manage the data in lake seperately, then copying it outside Eventhouse might be a better way think about it.