Power Apps – DB Reality!
Power Apps - Database Reality
I love the idea of Power Apps, because we all love Power BI cross-filtered charts and analytics (you do, right?). Power Automate has huge potential too. So yes, we’re pretty much sold on the whole Power Platform thing.
But, of course, are there any caveats..? Power Apps is not as mature and hammered out as Power BI. Which is a shame, because to get data insights out, you need data in. Even if that’s additional data to augment the existing or streamed/IoT data sources. For over 2 decades we’ve used Microsoft Access and VBA for that (it’s quick, powerful and cheap – and still is), then Winforms in C#, then gave up with doing their QA for them on WPF and UWP. So we stuck to Access and WinForms, especially as Microsoft web based solutions were dragging out Forms Based ASP.NET (and we’d done more than enough of that) whilst the more open source framework based MVC remained somewhat half-baked. We checked out Access Web Apps (the worst of all worlds) and LightRoom (potential, but a forerunner) and both of them pretty much got shelved by Microsoft. Because they had Power Apps coming. And I think 2021 is when they will really take off.
Back to the plot – Power Apps with real databases (not SharePoint or Excel files, neither of which are “delegable” ie guaranteed to deliver confident queries with more than 2,000 records without a mass of hassle). After all, we generally deal with millions of records, not thousands. So after seeing how excellent Power Apps was with running up quick screens on both Android and iPhones (or tablets and even browsers), we did some test apps and rolled out a client one for UAT. So far so good. But it revealed those caveats. Let’s go back to the drawing board with a base app for repro – a stripped down Mini Timesheet App.
Mini Timesheet Test App
Keeping it simple to avoid unnecessary fields, we have:
- TimeID: Integer (Primary Key, AutoIncrement);
- StartDate: DateTime (formatted as simple Date);
- Status: Integer for DropDown Lookup;
- Notes: Text (Multiline in App, nvarchar in SQL Server);
- Hours: Decimal, with a SQL Server Check Constraint < 8.
Overriding record-level Save icons are the top global ones:
- Save Basic: Use ForAll to save any changes on every record in one hit.
- Via Collection: Additionally use internal Collection object to “regulate” the records pre-save.
- Error Context: Hold any backend errors generated in client-side object.
Now we’ll check out their reality…
The fact is, record-level saves are kid’s stuff. Users want to see multiple records on the same page – the old “repeating table” setup. Power Apps does this with a “Gallery”, which works well. Until you want to edit as well as just view them. In this case, folk understandably want to edit a few entries at a time. With record-level save, only the current record is saved, with the remaining ones ignored – so on refresh, they’re effectively wiped clean of any additions! Not what users want, or even expect. Quite frustrating in fact.
Fortunately, Microsoft understand this (they’ve been doing it for quite some time…) so they’ve put forward the “ForAll()” formula command, to take an action on each object within it. Only it doesn’t work quite the way as expected either – you can make it work, but it exposes a whole load of internal workings you may wish you’d never have to scrape away at. And those issues (with resolutions – don’t worry!) will be covered in the next part of this 2-part posting.
CREATE TABLE [testing].[tbl_Time]( [TimeID] [int] IDENTITY(1,1) NOT NULL, [StartDate] [date] NULL, [Hours] [decimal](9, 2) NULL, CONSTRAINT [PK_testing_tbl_Time] PRIMARY KEY CLUSTERED ( [TimeID] ASC ) WITH (STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, OPTIMIZE_FOR_SEQUENTIAL_KEY = OFF) ON [PRIMARY] )
ON [PRIMARY] TEXTIMAGE_ON [PRIMARY] GO