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    
 
   
RobKoelmans
post May 24 2017, 01:10 PM
Post#21



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


Hi Ryan,
Yes, it is possible to import from O365 to SharePoint2016 provided you use the right version of SQL-Server (SQL2014RTM). I posted it somewhere here before. If you can't find it, I can get you the exact quote.

Deploying your own SharePoint has to be with bought licences for Windows Server, SharePoint, SQL-server (AWA's use SQL-server in two ways, by SharePoint and by the Access Web Service). Or you can have a SPLA agreement with Microsoft through a distri (Insight or Ingram Micro over here). You need quite a big server regarding memory (at least 128 GBytes of RAM for physical server, at least one virtual server for SharePoint and at least one virtual for SQL-server, preferably 512 GByte Ram, 1 TByte SSD's with 1 GByte ramcache for write spikes).

Our estimation is 3000 euros a month for hardware write off, rackspace, bandwidth, monitoring, support if based on SPLA. We have three 768GByte servers with 2 x 10 Gbit/s network connections between each other and 37 TByte each that run approx. 60 servers of customers at the moment, so we're going to put it up there and see what happens. We're already paying for datacenter licensing, so we may run as many servers as we want. SQL-server is the expensive one, so you have to go up from paying per user to pay per core asap (and get behind that as far as possible until performance becomes an issue).
Hope this helps,
Rob
Go to the top of the page
 
ryan996
post May 31 2017, 04:01 AM
Post#22



Posts: 76
Joined: 16-June 13



As a follow-up, I contacted Rackspace, and the cost and information is very similar to what Rob has posted. It will be between USD2K-$3K per month for licensing (SP, SQL Server, Windows Server) and hardware requirements without any per user fees. I don't think MS allows their partners to license SharePoint or SQL server on a per user basis like O365, so you're stuck buying full licenses. Obviously, this is a huge increase in cost over O365, but it has the benefit of not running into any of the throttle limitations on O365. For development and debugging purposes, O365 was great. However, if you're running large dataset operations like I am, and you want to go into production with your app, you'd want to move to an on-premise solution anyway.

If your client or your organization has an existing on-premise SharePoint license, I would definitely recommend moving your apps out of O365 before April 2018. Don't bother with PowerApps. PowerApps can't invoke SQL triggers (yet) and the forms and views leave much to be desired for corporate users who are working on desktops rather than tablets or iPhones. Do you see ERP vendors like Oracle/SAP think their users are going to be interacting with ERP systems on a mobile device rather than on a traditional PC?

All of us Access Web App developers know what a great product AWA is. If you're developing Apps for corporations, you could build customized solutions, business logic and algorithms in a very cost and time effective manner. You could build better solutions than off-the-shelf commercial software packages. I thought AWA complemented the MS PowerBI/Apps suite perfectly by essentially behaving like a user friendly code-editor for creating robust SQL-databases with a .NET front end.

I am very disappointed in how MS has treated their Access Services users in O365. I feel very strongly that MS should follow the same "lifecycle policy" on the O365 platform as they have on the "on-premises" platform. Perhaps we shall need to organize some type of campaign to extend this 12 month deadline.
Go to the top of the page
 
RobKoelmans
post May 31 2017, 07:57 AM
Post#23



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


Hi Ryan,
There are conditions to prevent paying twice if we're providing SharePoint to customers that already pay for SharePoint on premises. But - since we're aiming to buy everything off to flat user fee - it will not help us. Getting Access 2013 Web Services installed and configured was a daunting task, especially in SharePoint2016. It took us a six week support case discussion with Microsoft and even now we still not have it running with https, only http. We have publishing rules in TMG2010 to get it in https to and from the outside world (that was necessary already for the x509 client certificates that we use). The upside is, that performance is way better compared to O365. Really big datasets or triggers/datamacros ran in all sorts of trouble on O365. We completely got rid of those issues on premises. A giant relieve.

PowerApps can invoke SQL-triggers if you use your own very simple custom WebApi. We use that all the time to create JSON nested tables in response. They go directly into PowerApp Collections without iteration from us. For corporate desktop users we still can still use AWA browser sessions, but - even on those - PowerApps work more friendly if you standardly work with offline designs (that retrieves and submits at the beginning and end of a session). With touchscreen all-in-one desktops, it's a nobrainer to users, also because PowerApps is so blazingly fast with local data. Event the fastest websites feel a little sluggish after that (and an AWA-page is not one of the fastest sites). Regarding submit/retrievel-like working, we hardly modify documents but always add new versions. But - in case - we always submit the value that was originally read along with any changed values, so we can reject in the datamacro (or go into arbitrating logic that includes the difference of the original value and the current value into the new value). We haven't created that kind of logic yet because we've had no case for that but it's quite simple.

PowerApps is extremely powerful, but also extremely difficult to learn. There's a big list of techniques you'll find hardly anywhere. In C#/C++, you would have to build those techniques yourself first, but that would have to get you in a different line of business. I'm constantly baffled on PowerApps. Of the most spectacular things there's not even a word about on the community forum (i.e. IsMatch()). Even after months with a couple of programmers, you'll find ways to do things more simply or faster.
Rob
Go to the top of the page
 
GroverParkGeorge
post May 31 2017, 08:17 AM
Post#24


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


Unfortunately, so far pleas for a stay of execution among the MVPs who have spoken up have fallen on deaf ears in Redmond. And, equally unfortunate, in my personal opinion, the expressions of support for this move have been at least as numerous as the complaints.

This is NOT an "Access" decision; this is an "Enterprise" decision. While it can't hurt to make your views known, I'm not particularly optimistic. The people who call the shots are looking five years out--and that means PowerApps, not AWAs.

This is a done deal, I am afraid.

It's actually painful to me to read Rob's level-headed, experienced, evaluation of PowerApps. "PowerApps is extremely powerful, but also extremely difficult to learn." No kidding.

And we're being pushed from the relative straight-forward Access Web Apps approach head-long into the PowerApps approach....

No, I'm not particularly optimistic at all.

It's interesting to note that those of you working with enterprise level applications find the cost of a fully-licensed SharePoint service (quoted as $2000-$3000 US per month) to be reasonable for the kind of solution you're building and maintaining.

That's a big part of our problem, I am afraid. I would wager that the majority of AWAs actually built over the last few years were on Office365, were deployed to a couple of dozen users, and cost less than $200 - $300 US a month to host. Those AWAs are going to go away, leaving the field clear for the enterprises with the needs and resources to continue on the on-premises path. But even you guys are going to be cut off at some point, and that's even worse, in some respects.

I'm pleased to see and follow your discussion of options, plans and paths. It does offer a way forward for those with the needs and resources and the courage to keep trying new things.

Who knows, Microsoft has changed its mind before--lots of times. wink.gif

--------------------
Go to the top of the page
 
GroverParkGeorge
post May 31 2017, 08:21 AM
Post#25


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


I just popped over to Access Uservoice to see if there might be something relevant. It's shut down. Read-only posts are visible, but no new suggestions, comments, or votes can be submitted.

--------------------
Go to the top of the page
 
RobKoelmans
post May 31 2017, 02:17 PM
Post#26



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


In my opinion MVP's should advocate embedding AWA-DataMacros in Access Desktop. They have all the code available for that. Access would only have to group linked tables by their external source and present them in the datamacro designer environment as a link source you can compile datamacros to. If that wouldn't work they could restore honor to the adp-project mode and provide for AWA-datamacros that compile into T-SQL triggers and procedures in there. Why not have Access Desktop as backoffice environment to PowerApps this way? The database can also SQL-Azure in case they're worried about CloudFirst. A lot more suitable to PowerUsers than the CDM-SDK they came up with a couple of weeks ago. The Access Group would be free to do so because the enterprise decision concerned AWA, not desktop.


They can easily extend the PowerApps SQL-Connector to support StoredProcedures and UserDefinedFunctions or whatever their new name is in SQL-Server (I keep forgetting). We don't use the SQL-connector because it doesn't even support a row event trigger but - to feed a PowerApp Collection - the SQL-Connector is parsing in JSON already. It's ashtonishing they support their own highend database products so badly, both regarding SQL-Server and Access Desktop. Desktop Excel and Word - both having good connectivity with SQL-Server - would become better integration with PowerApps by that route as well.
Go to the top of the page
 
2 Pages V < 1 2


Custom Search
RSSSearch   Top   Lo-Fi    11th December 2017 - 08:02 PM