UtterAccess.com
X   Site Message
(Message will auto close in 2 seconds)

Welcome to UtterAccess! Please ( Login   or   Register )

Custom Search
2 Pages V  1 2 >  (Go to first unread post)
   Reply to this topicStart new topic
> Access Services (web Databases) Is Dead?, Access 2013 Web App    
 
   
Printmark
post Apr 13 2017, 09:15 AM
Post#1



Posts: 33
Joined: 29-January 13



Just found this blog by accident!

https://techcommunity.microsoft.com/t5/Offi...7WcEPoGPY.gmail

It states: We no longer recommend Access Services for new apps. This feature will be retired from Office 365. We will stop creation of new Access-based apps in SharePoint Online starting June 2017 and shut down any remaining apps by April 2018.

If true, this really bites. I've built a large part of our everyday business processes on this platform. Now what, doesn't sound like the Power Apps is a good alternative. Do I need to go to Quickbase?? is it similar?

I'm the learn what you need as you go type of person, so any change is the same as starting all over from scratch.

Printmark
Go to the top of the page
 
nvogel
post Apr 13 2017, 09:21 AM
Post#2



Posts: 811
Joined: 26-January 14
From: London, UK


See the following threads:

http://www.UtterAccess.com/forum/index.php?showtopic=2042977
http://www.UtterAccess.com/forum/index.php?showtopic=2043264
Go to the top of the page
 
GroverParkGeorge
post Apr 13 2017, 09:29 AM
Post#3


UA Admin
Posts: 31,203
Joined: 20-June 02
From: Newcastle, WA


Yes, we've been talking about this here at UA for a while, and in other venues.

You have until "April, 2018" to move and replace your AWAs if they are on Office 365. Normally, I wouldn't stress out over difference between the beginning of April and the end of April, but this is such an alarming timeline, that 30 days might well matter.

If you have an on-premises SharePoint site where you host your AWAs internally, you have until the end of the normal lifecycle of the last version of SP to support them, probably 5 years, or 10 years. I have not tried to dig out those details from MS's Lifecycle sites myself. If you're on SP on-premises, though, it will be worthwhile to look it up.

I have no recommendation for an alternative INTERFACE. PowerApps, in my opinion, are very much a long shot as a possible path to pursue. It'll be a race to see if PowerApps are developed sufficiently to encourage adoption by Access people before-or within a reasonable time after--AWAs are removed from Office 365.

On the other hand, rescuing your data is not a difficult task. I've blogged about that here. My first choice is SQL Azure, as are my second and third choices ohyeah.gif That said, the "official" Microsoft recommendation is to export your AWA's tables to SharePoint lists. There is one advantage to that approach. Accdb/SP List solutions can run in off-line mode.

I have no idea whether this Quickbase is a reasonable alternative, but I have my doubts. Investigate now, though, while you have time to make an orderly transition.

--------------------
Go to the top of the page
 
Printmark
post Apr 13 2017, 09:46 AM
Post#4



Posts: 33
Joined: 29-January 13



I have everything in hosted Office 365/Sharepoint, not on premise.

I feel a bit cheated here by Microsoft, I was also one of the ones that "adapted" in 2013 to the new platform (away from 2010), had to learn the new way, and now I have to do it again! It just really turns me away from Microsoft as the solution. If I convert to the Sharepoint lists with Power Apps.. what do I get, another 3-4 yrs?? just crazy.

What about accesshosting.com? would they be an alternative solution, just move the info off of Microsoft's Servers?

Thanks for the reply's, I'm just trying to explore my options.

Printmark
Go to the top of the page
 
GroverParkGeorge
post Apr 13 2017, 09:46 AM
Post#5


UA Admin
Posts: 31,203
Joined: 20-June 02
From: Newcastle, WA


On a separate, but related topic, getting your data safely out of harm's way.

What I've discovered recently is that Referential Integrity, as it is implemented in your AWA's SQL Azure database, is preserved by using the dacpac method I describe in my blog post. The resulting tables have the original Foreign Key restraints from your AWA's SQL Azure db, a very good thing.

RI is theoretically preserved by exporting AWA tables to SharePoint lists, but I've had failures when trying to do that, so I'm not really highly confident in that process for any but the simplest of table schema. It worked for one AWA, but not for another one. There were too many records in one large table--over 43,000 postal code records. I suspect I hit some internal SP limitation that caused the failure. I DID get all of the records into SP lists, but without even the SP version of RI, it's hardly worth doing, IMO.

Converting the SQL Azure tables to local Access tables is the simplest, quickest, method, but I have found it doesn't preserve any Foreign Key restraints. Bad juju--to use a slightly technical term--and only worth doing as a last-ditch salvage method if the deadline is approaching and you have run out of options.

All in all, if you can set up a SQL Server instance, local, network or hosted, or if you can get a SQL Azure account, migrating your AWA's database with a dacpac is the most complete and probably the next quickest approach. I suspect you could also go to Amazon's Web Services (AWS), or possibly another RDBMS, but for the most part, those are probably not the most obvious of choices for an Access developer.

One final thought on alternatives. I understand there is a way to get a very low cost, possibly even "free" Azure account that would work as a place to host your migrated SQL Azure databases. I've not yet had time to investigate the details, but it may be that is a good way to at least try it out.

--------------------
Go to the top of the page
 
GroverParkGeorge
post Apr 13 2017, 10:07 AM
Post#6


UA Admin
Posts: 31,203
Joined: 20-June 02
From: Newcastle, WA


I'm not at all sure PowerApps with "anything" is a viable alternative, although MS is devoting a lot of resources to that initiative and they may well grow up to be a possible solution.

In my mind, it's basically a race between the end of the line for AWAs and the minimum threshold of capability for PowerApps. We have a firm deadline for the former, but only projections for the latter.

At this point, PowerApps can only consume flat files, e.g. csv or single SP lists. They don't do joins; they don't understand relational data yet. And, they can't even connect directly to an accdb, if I understand correctly.

What that tells me is that, you can export your Access data to SP lists, or to a csv, etc. Then connect that data to a PowerApp interface, but you've lost any "Accessiness" in the solution at that point.

All of that can change, of course. And there is something called the Common Data Model being developed in the PowerApp environment which promises to fill those gaps.

To me, the only sensible thing for an AWA developer is to pick an alternative interface tool and get to work. Salvaging your data is going to be only a small part of the project.

If that means you no longer count on Microsoft and Access, well, unfortunate as it would be, your clients' needs come first.

--------------------
Go to the top of the page
 
GroverParkGeorge
post Apr 13 2017, 10:12 AM
Post#7


UA Admin
Posts: 31,203
Joined: 20-June 02
From: Newcastle, WA


Re: accesshosting.com.

They are pretty much in the same boat as everyone else. I don't know much about their offerings. It might be an interim solution, but keep in mind, ALL SP support for Access Web Services will end in a future version of SharePoint, and that means they'll have to plan for that transition as well.

--------------------
Go to the top of the page
 
Printmark
post Apr 13 2017, 10:43 AM
Post#8



Posts: 33
Joined: 29-January 13



Thanks for your insight.

If someone with your expertise is struggling to find solutions, then I know I'm in trouble!
I'm going to dedicate a little time in reviewing the Quickbase product, at first glance it looks promising, but with an added cost (of course).

I know I won't be able to "convert" the AWA to Quickbase. However, if I have to learn something new and start over, I want it to be around for a while.
My hope is I can import/export our of excel tables so we don't loose our existing data. Once i have it in the tables, I'll just have to see what I have to work with for building the logic.

I've learned my lesson this time, fool me once, shame on you, fool me twice, shame on me. - This makes twice.

Printmark
Go to the top of the page
 
RobKoelmans
post Apr 14 2017, 02:51 AM
Post#9



Posts: 434
Joined: 25-November 14
From: Groningen, Netherlands


Turned my reply into a separate post.
Go to the top of the page
 
JulianKirkness
post Apr 14 2017, 10:29 AM
Post#10



Posts: 112
Joined: 6-February 15
From: Canterbury, UK


I have decided to give Zoho Creator a go - considerably less expensive than Quickbase too.

It has a decent set of features, a language somewhat more powerful (Deluge) than AWA's Data Macros and is mobile ready. It also has reporting, graphics, multi level security etc.

I recently passed an online exam an am now a Certified Developer - and am now working on a review of the platform for my blog.

Hope this helps?

--------------------
Julian Kirkness
Access MVP
Go to the top of the page
 
GlenKruger
post Apr 14 2017, 04:20 PM
Post#11


Utterly Crispy UA Forum Administrator
Posts: 8,766
Joined: 29-September 01
From: Edmonton,Alberta,Canada


Julian I have also been looking at Zoho Creator.

--------------------
Human nature, it is a funny thing and the hardest thing to program to prevent.
Glen Kruger KNKConsulting
MS Access MVP 2013-2018| Wrox Techincal Contributor
Go to the top of the page
 
Printmark
post Apr 18 2017, 07:22 AM
Post#12



Posts: 33
Joined: 29-January 13



Thanks for the suggestion, I'll check out Zoho as well.

Quickbase looks like a good platform, but as mentioned, it is rather pricey. Especially when you need the premium features but only have 10 or so users. You have to pay for the minimum 20 (up to 40 users) depending on the features, that where it gets cost prohibitive.

Is there any known alternative that would "convert" the AWA to a different platform?
(I really dread having to recreate everything that I've been working on over the last 3yrs.)
Go to the top of the page
 
GroverParkGeorge
post Apr 18 2017, 08:03 AM
Post#13


UA Admin
Posts: 31,203
Joined: 20-June 02
From: Newcastle, WA


I suppose some enterprising organization or developer could try to develop a conversion tool for AWAs, but I've never heard of one.

--------------------
Go to the top of the page
 
nvogel
post Apr 18 2017, 10:37 AM
Post#14



Posts: 811
Joined: 26-January 14
From: London, UK


QUOTE
I really dread having to recreate everything that I've been working on over the last 3yrs

Many or most organisations expect return on investment for software projects within 3 years, which is why software regularly gets written-off and junked. Software vendors are aware of that and take advantage of it when they release new features and discontinue old ones. Change is the only constant and this can be seen as a positive thing. From a personal perspective if you are a technology professional it means opportunities to learn new things rather than letting your skills go stale supporting the old ones.
Go to the top of the page
 
GroverParkGeorge
post Apr 18 2017, 10:44 AM
Post#15


UA Admin
Posts: 31,203
Joined: 20-June 02
From: Newcastle, WA


QUOTE
"From a personal perspective if you are a technology professional it means opportunities to learn new things rather than letting your skills go stale supporting the old ones."


In the Access world that's particularly important, IMO. One of our problems has been reluctance to take anything seriously that didn't fit the mold of Access circa the 97 version, or maybe 2003. While many of us regret the demise of "Access in the Cloud, 2.0", we ought not to let that [ahem] cloud our view of the opportunities opening up as a result.

I'm not ready to call PowerApps the solution to all our problems, it certainly seems to promise a lot of good things.

--------------------
Go to the top of the page
 
Printmark
post Apr 18 2017, 12:04 PM
Post#16



Posts: 33
Joined: 29-January 13



But I'm not an IT Professional or Access Developer.
I'm a Graphic Artist in the Sporting Goods Industry who knows a little about building Access Web Apps.

This product was marketed non-professionals (like me) as a "no code" solution. I quickly learned that if you wanted any logic at all behind the data, then you had to learn the macro language, so I read solutions and ask questions on this forum to figure out how to do what I wanted done, with great success for not really knowing what I was doing.)

The work that I've done on building our custom business modules (Order Entry, Order Tracking and Inventory) are exactly what we needed, and use everyday. To have that yanked out from under you, and not knowing enough about what platform to move to, or even a clue as to how to recreate what I've already manged to piece together, really stinks!!. I have a ton of time in learning this platform, all for nothing.

I suppose if I were a IT professional, I would look at the change as job security. But for the dummy that went for the no-code solution to run a business, it is more like having a MOAB dropped on you.

Printmark
Go to the top of the page
 
ryan996
post May 24 2017, 07:27 AM
Post#17



Posts: 76
Joined: 16-June 13



I think the most feasible solution at this point for those of us who are using O365 to host our AWAs is to move to another tenant on Azure. For instance, deploy SharePoint 2016 on a virtual machine and load AWA as a SQL Server database. There could even be some benefits as there won't be a 1GB size limit or 1 minute limit on running a data macro. It would be helpful if anyone has written a step-by-step blog on carrying out such a deployment.
Go to the top of the page
 
GroverParkGeorge
post May 24 2017, 08:01 AM
Post#18


UA Admin
Posts: 31,203
Joined: 20-June 02
From: Newcastle, WA


Check my blog series. The process would be the same.

--------------------
Go to the top of the page
 
GroverParkGeorge
post May 24 2017, 08:03 AM
Post#19


UA Admin
Posts: 31,203
Joined: 20-June 02
From: Newcastle, WA


When you say "deploy SharePoint 2016" on a virtual machine, do you have any insight into licensing costs for your own instance of SharePoint? It's not something I've investigated lately.

--------------------
Go to the top of the page
 
ryan996
post May 24 2017, 09:36 AM
Post#20



Posts: 76
Joined: 16-June 13



I will need to maintain the functionality of my AWA including all the data macros, triggers etc, so moving to SharePoint Lists, PowerApps or just moving the data into SQL Azure is not a solution for me. Furthermore, my users interact with the app through the web front end, while most of the back-end data is synched with their ERP system using SSMS. Though moving the data to SQL Azure is straightforward, we do not have the resources to build out a whole new front-end in .NET.

Consequently, my objective will be to get my AWA moved out of O365 by April 2018 to an "on-premises" 2016 SharePoint deployment in Azure, which theoretically should maintain functionality of my web app for another 5 years.

I just read that it is not possible to deploy an existing app package from an O365 environment to on-premises SP, which is exactly what I'd be trying to do. Rob says that he has done just that as long as the app is deployed on SQL Server 2014, so perhaps he can chime in here.

I haven't looked at licensing costs, but it would be possible to get a 30 day trial account in Azure just to test if such a deployment is feasible.

Instructions on deploying a SharePoint Server in Azure are on this blog:

http://thuansoldier.net/?p=4863

Another option is to use another company that hosts SharePoint Servers, such as Rackspace. https://sharepoint.rackspace.com/
(I have not spoken to them about deploying an AWA from SPOnline and have no affiliation, but I shall contact them to see what they think.)
Go to the top of the page
 
2 Pages V  1 2 >


Custom Search
RSSSearch   Top   Lo-Fi    13th December 2017 - 07:25 PM