Posted in PowerApps, SQL Server

Power Apps Connection References to SQL Server

Power Platform is part of the Microsoft universe of products, for lack of a better phrase. But the one thing I find interesting is that the default connectors for data in the PowerPlatform sphere is Dataverse or Sharepoint. At least, when I see people talking about PowerApps is you’re connecting to one of those two connectors for your data. (Fun fact, PowerApps solutions use Dataverse to store configurations.) One would think that SQL Server database, wherever it may live Azure or on prem, would be part of that combination, but it’s actually considered a Premium connector.

Continue reading “Power Apps Connection References to SQL Server”
Posted in PowerApps, SQL Server

Unpacking and Packing Solutions with PowerApps CLI (PAC)

As a developer, I have two things I have to do: 1. Check code into source control and 2. Make sure I can use that code to deploy to any and all environments repeatably and successfully. The question then becomes, how do you do this when the development environment is in a portal?

Continue reading “Unpacking and Packing Solutions with PowerApps CLI (PAC)”
Posted in PowerApps, SQL Server

Deploy PowerApps – Solutions vs Apps

One of the big challenges I had was how to move the app from different environments. Following best software development practices, we have a development environment in our Power Platform that uses a development database as well as a production environment that points to a different production database. This has been a multi-step process with hurdles along the way.

Continue reading “Deploy PowerApps – Solutions vs Apps”
Posted in PowerApps, SQL Server

PowerApps Delegation & Database Design

When I write a SQL Query, I never have to worry if the way I’m writing a query will automatically create a limit on the number of records being returned if I’m not specifying TOP or OFFSET…FETCH. If my query wants to return 1 million records, it will return 1 million records.

PowerApps doesn’t work that way. It uses something called delegation to figure out if the data source can do the filter work required. Otherwise it puts a limit on the number of rows returned. By default, the value is 500 but you can change the limit to 2000, as seen below.

Continue reading “PowerApps Delegation & Database Design”
Posted in PowerApps, SQL Server

Working with PowerApps

I mentioned a while back that I’ve had a chance to work on a PowerApps proof of concept. It’s a little unusual for a database person like me, but it makes sense for what we wanted – a relatively simple way to expose data were collecting in a SQL Server database to allow people to view and in some cases, update what we’ve been collecting.

Working through this, I hit all sorts of problems that took a lot of baby steps for me to work through. Some of these points required my understanding of PowerApps worked and some just took me being curious and investigating on my own.

The issues came down to:

  • Making database design decisions needed because of delegation limits and the inability to call a stored procedure to make things like complex selects or even writes easier.
  • A misleading error as to why I couldn’t deploy the app
  • Using PowerApps CLI to unpack and pack the code for deployment
  • Using different SQL Server instances for different environment

This is a proof of concept still waiting for final decisions for the go-ahead. Whether we use this or not, I feel like I learned a lot from these issues that was worth sharing. I’ll share of these lessons learned so stay tuned for the links going forward.

Posted in PowerApps

Remembering How to Learn New Things

Photo by Pixabay on Pexels.com

It’s been a while since I’ve blogged. It’s just been really busy around here. One of the things that’s kept me busy – from the work perspective, at least – has been learning something new: PowerApps.

If you haven’t heard of it, PowerApps is a low-code offering from Microsoft to quickly build and share apps. I just need a very simple, internal facing application so PowerApps fits our needs. I have dabbled with programming over the years so I’m familiar with a lot of the concepts needed. Plus I’ve spent my career working with developers so I’ve absorbed their processes and approaches as the daily stand-ups covered the different bugs they were working on. Being exposed to the development process and lifecycle has been invaluable to figuring out how to make this work. But there’s still a learning curve as I do this myself.

I have to say – I’ve been enjoying working on this project is working with something new. It’s a good reminder of how to learn something a little outside my normal “bag of tricks”.

So how am I learning PowerApps?

  • Doing my homework before my work. I knew this project was coming so I was able to spend some time learning about PowerApps before I did anything else. I had access to various courses so I watched some of them online. This meant I could hit the ground running – well, maybe not running – but I could get started faster because I knew what the screen looked like, where to find the basic things, and have enough information to understand what I needed to look for as next steps.
  • Making use of the data samples that are provided. PowerApps comes with sample data that I used before I even touched that data that I wanted to work with. I was able to create some screens that interacted with that data so I could learn different items and behaviors that I was then able to apply to the various pieces of the application. Sample data like this is not something I would have thought to look for, but once I realized it was there, it made it much easier for me figure out the basics without having to figure out how to read the data from a database or create a table in Dataverse or import from Excel, etc.; there are a bunch of caveats about data limits and working with data from sources so it was one less thing for me to focus on as I got started.
  • Breaking each piece down into small chunks. Being brand new to PowerApps meant that I didn’t know any of the commands, which meant I had to look up how to do pretty much everything. If I want my button to do X, Y, and Z, I really need to understand what X, Y, and Z entail. So instead of trying to do everything at once, I could work on making the button do X and understand what’s behind making that work. Once I got that piece in place, I could then work on Y. If Y required more involved logic, I would break that down into something smaller. But by looking at each step and really understanding what’s involved, it probably helped me put everything together much faster.
  • Fine tuning my search keywords to really hone in on what problem I am trying to solve. This really is the key to most things that we do as we learn something new, right? And in some ways, this was the more frustrating piece that I’ve had to deal with. It takes a lot of trial and error to figure out how to describe the behavior you are trying to accomplish in a way that those who know the product talk about it. It took me multiple days to find out to make a particular action work the way I wanted it to and it took about 5 minutes to implement and test 6 lines of formatted code once I found the answer. Why did it take so long to find the answer? Because it took time for me to try to get alternate solutions to work based on other searches and then refine my search to get the right answer for my scenario.
  • Reminding myself that just because something is designed for a “non traditional programmer” like me, it’s still programming and it can still be hard. One of the realizations that I’m coming to is that there should be a reframing about tools we label “no code\low code” solutions. The purpose of these is to help speed the development process by allowing business users, or “citizen developers”, create applications without the requirement of knowing how to code or minimal knowledge. What gets lost is that it is still programming. While the barriers to get started are lower, i.e. using of WSIWYG interfaces, we do these solutions as a disservice by forgetting about the “code” part. You will still want to understand basic programming principles to truly make these good applications – responsive screens, security and application permissions, accessibility, coding standards, source control, QA & testing, deployment, etc. My joke has always been that programming made me want to throw things and I’ve hit that frustration level working with PowerApps a few times. But reminding myself that this is programming has actually helped reset my mindset by forcing me to stop, recognize that it’s hard, take a breath, and reattack the problem from a different direction.

I’m sure there’s a lot more details about what I’ve learned so far that I should probably throw a couple more posts together.; hopefully I find some time for that. But there are still some cool things that I’m looking forward to exploring more – like using the VSCode extensions to check my work into source control and potentially even code the app directly (!), using the Test Suite to create unit tests, and learning how to deploy my app to different environments.

Will I become a full time PowerApps developer? Probably not. I still like my T-SQL but I’m happy to have another set of skills for my toolbelt. But if nothing else, this has been a good reminder that we need to be open to learning new things along the way.