We understand the significance of catering to the needs of the more technical users, such as engineering techs and database administrators (DBAs), who require direct access to the underlying database. RigReports offers various database access methods to accommodate their specific requirements, ensuring they have the necessary tools to effectively manage and analyze the data.
Data is the lifeblood of our applications, and ensuring its freshness is vital for accurate decision-making and analysis. While designing the WellOps platform, and later RigReports, we chose to implement a live database infrastructure to provide users with up-to-date and synchronized data across multiple applications and interfaces, eliminating the need for data synchronization between transactional and analytical databases.
At Mi4, one of our core beliefs revolves around empowering our users with unparalleled data ownership. We firmly believe that users should have complete control and access to their data, enabling them to make informed decisions, gain insights, and derive value from this digital asset.
To achieve this goal, we have developed a comprehensive roadmap that I will be talking about in a series of blog posts. Some of these measures are already implemented, and the rest we will be covering as we implement them so you can experience this journey with us in real time.
Dates in the Oil & Gas industry data can be a little tricky.
Especially when aggregating data, such as production volumes, to a daily level, and trying to connect multiple tables with date columns.
Some tables, such as tank levels or production volumes, could be based on a Gauge Date (aka Report Date) since the data is measured, aggregated, reported or “gauged” on that date (today), but in essence it is yesterday’s data, or to be more accurate, it is the data for the 24 hour period that began yesterday at the contract hour (e.g. 6am) and ended today at that same time, or the Production Date.
Other tables could have actual dates, such as sales tickets, run tickets, operation logs, etc.
The Energy Tech Night, or ETN, which is hosted by the great folks at Digital Wildcatters, is by far the wildest and most fun energy tech event of the year, and I’m not just saying that because I went home with an awesome gold chain around my neck!
In this episode, Talal Nehme shares insights into the inspiration behind the development of RigReports and how it solves key challenges faced by our users. He also provides a sneak peek into the future roadmap planned for RigReports.
The podcast episode can be found on Apple Podcasts, or you can watch the YouTube version on this page.
We hope you enjoy listening to this episode and look forward to bringing you more insightful conversations in the future.
Most websites that offer Nutrition Facts and Food data lookup functionality seem to offer a top down, food driven search function. First you select or search for a food and they return the nutrition facts for your selection. I was looking for the opposite and I couldn’t find it. Thanks to Power BI, I was able to build one in minutes, here’s how I did it…
One evening last week I wrote an important email to a client and I thought I sent it but I didn’t. I wanted to let the client know their project is ready so in the morning they can start using it. And after I finished writing that email, while checking for typos, I got distracted by something, and by another thing…and I never sent it that night.
Over a decade ago I had the pleasure to create a small desktop application for Chammas Cutters, this was the Grain Selector tool pictured above, and it helped their clients quickly determine how much gas-generating grain to use in the application of their chemical cutter tool.
While pretty basic (and written in it) the desktop application served a good purpose for the past 10 or so years. Prior to the desktop application, clients would have to resort to a rather bulky and complicated spreadsheet-type catalog tables, which can be more time confusing and can lead to human error.
Now that it needed to be improved or rewritten, I decided to replace it with a Power BI report that took just a few hours to create. Here’s why I chose that path: