Book & Research Recommendations Azure BE > Access FE

[dalski]

Can anyone recommend a good book exposing common pitfalls...? I'm a complete novice in both Access & Azure. Seems that using an ODBC connection in MS Access exposes passwords... in the registry.... Also as I still have not finished my application which I am planning to sell as an .accde & Azure BE I am realising now that:

• Think I've made a mistake using functions in calculated queries does not seem a great idea in Azure; causing the BE in Azure to reconnect with the front-end greatly slowing down the app. Though Philipp Stiefel mentions this is looking better in MSSQL Server 2019. Layering the queries also brings me problems in the application crashing on the third layered query but maybe there's a problem with me referencing a bad incomplete calculated field in a query. It was getting very slow in the query editor on the third layered query so I jumped between the two. It's probably me with a bad reference or something
• Seems I should probably be using ADO recordsets (but rebind after updating due to bug in Access)
• I've already based most forms on queries... reducing the size of the recordset being worked with; though can get realy tricky with queries based on other queries with several tables & acheiving the new query to be editable

Research Material Known About

• Fundamentals Of Azure 2nd Edn - Michael Collier, Robin Shahan - does not touch on common pitfalls of MS Access & is more for hardcore languages/ web development
• Backends For FrontEnds Pattern - Microsoft Learn - does not seem relevant to MS Access
• Extend Microsoft Access Applications To The Cloud - Andrew Couch - Seems largely based on obsolete MS Access Web Apps & scanning contents I can't see any benefit here with guidance on common pitfalls with MS Access
• Access 2010 VBA Programming Inside Out - Andrew Couch - (read it); inital scan Azure was in the beta stages of development.
• Youtube codekabinett.com/eu - SQL Server Authentication - very good & based on @isladogs very helpful Security Challenges exposing weaknesses in MS Access to watch out for

Grateful of any guidance & tips. I'm posting a bit early as I'm trying to implement best practices for an Azure setup & know nothing about everything.

 

[Minty]

I'm not aware of any books covering the potentials and pitfalls of using Azure and Access as FE I'm afraid.
I have however developed a number of apps with exactly that set up, and most of what I know is based on experience and finding out the hard way...

You should move any FE functions into the backend source views, unless they are used on single records/very limited recordsets.
As you have discovered having function calls in Access on Azure linked tables is a non-starter for performance.

Layering queries - do this in SQL Views, there should be no need to do this in Access, SQL Views are much more tolerant of remaining editable with complex joins and sub queries than an Access query. They will also join multiple tables and handle sub queries much more efficiently than doing the same in Access.

You can make and then delete the ODBC connections in code on demand, which would hide the password and not be viewable in an accde.

 

[dalski]

move any FE functions into the backend source views, unless they are used on single records/very limited recordsets.

Layering queries - do this in SQL Views, there should be no need to do this in Access, SQL Views are much more tolerant of remaining editable with complex joins and sub queries than an Access query. They will also join multiple tables and handle sub queries much more efficiently than doing the same in Access.

Thanks @Minty, good news that SQL Queries are more powerful as I'm working on a bit of a pig at the moment. I'm not sure if I should try to upload to Azure & see how i go from there. I imagine this will slow me down massively as I'm so new to it & learning Access was hard enough (still know very little), or continue in Access where I'm more comfortable & trying to implement as much good practice with Azure as possible on my limited understanding. Then when it's all working then go to Azure? I think I'm going to fall to pieces in Azure with such limited info out there & being such a novice.

 

[isladogs]

I'm also not aware of any books specifically related to your question and don't consider myself an expert in Azure
You should be able to find some AccessUserGroups videos that would help your research

Just to correct any possible misunderstanding from a comment in post #1.
In the final link provided, with my agreement, Philipp Stiefel did an excellent demonstration of Access weaknesses based on an early version of my security challenge:

Encrypted Split No Strings

This example app shows how an Access database can be made reasonably secure against hackers whilst still allowing full functionality to authorised users.

www.isladogs.co.uk

Following that very helpful deconstruction, I completely rewrote the app to secure all the areas of weakness that Philipp exposed so successfully in that session

 

[dalski]

Just to correct any possible misunderstanding from a comment in post #1...
Following that very helpful deconstruction, I completely rewrote the app to secure all the areas of weakness that Philipp exposed so successfully in that session

Thanks Colin, was in no way meant to be a dig; but a token of gratitude for the valuable lessons on your site, & as stated in tutorials they were all designed to be solvable. Very grateful for the info.

 

[tvanstiphout]

> using an ODBC connection in MS Access exposes passwords
Not if you use this tip:

Power Tip: Improve the security of database connections | Microsoft 365 Blog

When linking to external tables using Open Database Connectivity (ODBC), Access offers to set up a Data Source Name (DSN). The DSN is quite convenient, giving us a graphic method to quickly build and specify an ODBC connection string without having to remember all of the syntax and parameters...

www.microsoft.com

With an Azure BE, you cannot program as-if you are on a LAN with an OnPrem SQL Server. The connection is likely 3 orders of magnitude slower.
It is important to cache all static tables, and even tables with regular adds and updates can be cached to some extent, as long as the cache expires each time the underlying table is updated.
It is important to do as much processing on the server as possible. That means server-side views (indexed if possible), functions, and stored procedures. Of course we need a high-quality database design.
Stacked queries like you wrote about can be acceptable, *if* in the BE.
You'll need to understand the tooling SQL Server has available for monitoring and optimizing performance.

All of the above requires expert programming. It may be too much to ask for a beginner.

 

[GPGeorge]

Although I also know of no good books on Access/Azure SQL, there are a lot of parallels between hosted instances of SQL Server and Azure SQL. You should find a lot more relevant resources by including SQL Server in your research.

The main design consideration, IMO, is that Access FEs with any remotely hosted databases need to be architected as Client-Server applications. The client -- Access -- should be as light-weight as possible, handling primarily interface tasks. All of the data management needs to be done in the Server database, or at least as much of it as possible.

That suggests that VBA functions that are data focused should probably be rewritten as Stored Procedures in the Server database. Views on the server should replace local queries in large part, although sometimes parameterized local queries can be reasonably performant. Think of it in terms of one general rule:

Move the least possible amount of data back and forth across the connection.

If you are populating a form for editing, load ONE record at a time in that form. If you are aggregating data for a report, do as much of that as possible in views, stored procedures or pass thru queries.

 

[isladogs]

Thanks Colin, was in no way meant to be a dig; but a token of gratitude for the valuable lessons on your site, & as stated in tutorials they were all designed to be solvable. Very grateful for the info.

It didn’t come across as a dig.
I just wanted to clarify how and why that video was done
I was very grateful to Philipp for exposing the weaknesses in that app as it prompted me into making significant improvements in subsequent versions.

 

[dalski]

Thanks guys, I get the gist to do as much as possible in the BE. Do we think carry on in Access, then think about Azure once I get it all working, or move to Azure now, whilst continuing to develop & test? I imagine I'd need to convert datatypes on incompatible types... & many things would that are working now, would no longer work until adressed in Azure. To which I see myself struggling at the first hurdle, not to mention the remaining hurdles.

I take no offence at all to my limited capabilities, few familiar faces here so we have a rough idea on my limited capabilities at this moment in time.

 

[Minty]

@dalski If you can get used to writing the queries in SQL Server, the syntax is virtually identical bar a few things (Text delimiters, Date Formats and string concatenation are a couple that spring immediately to mind) Get used to using YYYY-MM-DD.

You will then avoid some of the gotcha's that come when upsizing/converting, like referring to calculated fields within the same query they are created (You can't do that in SQL Server), and Access's awful nested way of displaying table joins.

There are also several really useful functions in SQL Server that can save you a bunch of time and effort.
Look at String_Agg(), Row_Number(), Concat_WS() as some neat ones for starters.

They take a little getting used to but (particularly the windowing functions) will outperform anything you can do in Access.

 

[GPGeorge]

Thanks guys, I get the gist to do as much as possible in the BE. Do we think carry on in Access, then think about Azure once I get it all working, or move to Azure now, whilst continuing to develop & test? I imagine I'd need to convert datatypes on incompatible types... & many things would that are working now, would no longer work until adressed in Azure. To which I see myself struggling at the first hurdle, not to mention the remaining hurdles.

I take no offence at all to my limited capabilities, few familiar faces here so we have a rough idea on my limited capabilities at this moment in time.

I would treat it as a normal software development project.

• Leave the current production application alone, except for required maintenance or bug fixes.
• Treat the new version as a development application, regularly updating data if necessary for testing as you go.
• Deploy a test version of the new architecture when it is ready, running it alongside the Access production application during that test phase.