I am enrolled in masters program and currently I am learning WCF services, their deployment and Microsoft Azure. I am working on an idea which I am hoping I will be able to pull in next 4-5 months.
I am hoping, if I could publish applications like powerpoint and excel or may be their basic functions on a Cloud via Azure so anyone can use those features without even having those applications on their machines over the web(only available to authorized personnel) .
I want to ask how viable above approach could be because it is still a very young Idea. And, It would be nice if I get some professional arguments and may be counter arguments.
Thanks a lot!!
Just use Citrix. They do this already.
Related
I'm starting a new project where we are expecting to migrate desktop based Access 2016 applications (with a lot of backend VBA and relationships between the tables) into SharePoint 2016 on-premise and very soon, SharePoint Online. From what I've been told, we'll be given site permission to a SharePoint site that we can do whatever we want with. I am hoping that with SharePoint 2016 on-premise and eventually SharePoint online means that there is a SQL Server and eventually Azure SQL Database that I can migrate the Access backend tables and queries, as I know SharePoint lists will be inadequate for this, despite the false notion that SharePoint lists are an equivalent substitute for database tables.
My concern is how to build the custom forms, perform the needed business logic, perform CRUD operations, and upload data in the form of Excel files from the SharePoint site to the backend.
I'm new to SharePoint and given that it does not support VBA, that Microsoft cut out Access Web Apps earlier this year, and they are phasing out SharePoint Designer 2013 and InfoPath, some research over the past week indicates my best options are building custom web application using ASP.NET Core and somehow deploying that to the SharePoint site and subsites that we have control over, or developing a lot of HTML, CSS, and JS to create the front-end interface. I had read about the Business Connectivity Service to get and post data to / from the SharePoint site front end and the DB backend, as well as using Javascript and AJAX calls to do CRUD operations between the database and the frontend. I looked into PowerApps and those seem insufficient, and I'm still trying to distinguish between SharePoint web parts and SharePoint add-ins.
Is any of the above even a feasible option? Could someone chime in on a better path to go about this? What technologies would I need to best go about this?
Support for moving tables from Access to SharePoint remains a choice and option.
So all of your VBA code etc. will work as before. The only real question is if you want to move your data to SharePoint tables in place of using SQL server.
SQL server tables are far faster than SharePoint tables.
However, you can certainly consider moving your tables to SharePoint. When you move your tables to SharePoint (or SQL server), then Access code, forms, reports etc. and EVEN your VBA code will work as before. What this means is that you continue to deploy the Access application to each desktop. The only difference is now your tables are on SharePoint, or SQL server.
The above choice does not result in a web based application.
So you can move the data, but your application will remain a desktop application.
If you looking to build a web based application, then Access is the wrong tool – you need to adopt something like Visual Studio.
So you can continue to use Access, and put the data tables into the cloud, or on-site SharePoint - but the application will be still desktop based.
I have used the following extensively over the last couple of years and I am happy with the experience:
Azure SQL Database as a back-end
Flow for automation and as an interface to the DB
PowerApps for forms, desktop apps and mobile apps
Excel for reporting (Get & Transform aka PowerQuery and DAX), especially for printing reports
Power BI for dashboards (limited use)
Yes, PowerApps has drawbacks, but there are a lot of realistic workarounds out there and new features/improvements are being added regularly.
I have also used SharePoint lists as data sources, but almost always then migrated to Azure SQL Database.
I'm not sure if this is the right place to ask this question. If not, please direct me to the right place.
We used to have an application that was created using VB and Microsoft Access. It was an application to score calls from Agents and would then run a few calculations and grade those agents based on a few algorithms.
We replicated all that Access data onto SQL but for some reason, we were just not able to connect the VB application to the SQL Database instead. The application was also outdated and we needed a change.
Can anyone suggest software/framework that can be used to create a new application with an ability to connect to a SQL database?
EDIT: We have a Microsoft Office 365 subscription. I was thinking of using PowerApps. I've never used it before. Does anyone think this could help serve my purpose?
I have extensive experience of using PowerApps to create applications connected to SQL Server (in my case Azure SQL Database), and am mostly satisfied.
There are some constraints, but not major. Please see these posts for some further information.
I would suggest PowerApps if you have Office365.
I am not very familiar with Access database till now i was only programming to SQL Server but now it's time to do so. I am building WinForms application which will be using Access database and i have some question related to that point if you don't mind. My application will be used by multiple users and there will be one access databsae. My questions as below:
Is there any problem with accessing access database in same time by many users or only one user can be connected?
If i develop my program to use access 2016 and some of my users will have diffrent windows version and also diffrent access version
will it works?
Should i know something else? :)
If your client want to have a file based database and this is a project constraint , MS Access is the best choice. If you want a more detailed advice, please let me know how many users will perform Read/Write or Read transactions, the size of the database and if the application will run in client-server mode in a LAN/WAN, Cloud or Remote Desktop environment.
Back to your questions:
Depending on these conditions you may range from 10 to 20/25 users. Remember that you can always try with MS Access and later upgrade to a MS SQL database in a couple of hours.
If your front-end application can link to a 2016 Access database, it will do that without installing MS Access to the clients that will run your App, i.e. the vb.net compiled App will install all needed drivers. If you develop your App within MS Access 2016 (Access Form and reports, some VBA) you can run it with the free runtime version of MS Access, but this only when no older version of Access is installed on the running workstation.
Please check with your client the real reasons for a file-based database...
To answer the questions as asked:
You might run into an issue with this, as access was really designed as a personal use database. Having anything more than a small handful of users hitting against it at once will in fact cause problems, as it's not really well designed for that purpose...
This should in theory be fine, as the application itself is interfacing with the database, not the end user...
It seems like you're taking a step backwards using access for this, and SQL might very well be better suited for this purpose. This isn't me trying to just bash access either, this comes from personal experience. Going with this sort of design is likely to cause you more headaches than good.
I'm looking at taking a possible contract role as an MS Dynamics developer. In the interim, I'd like to play around with x++. Am I right in thinking that the only code editor available is the one that ships with AX?
I'd really like a freebie alternative to use for now, but I haven't come across one.
Not sure that you can get something for free, but you can create a dynamics ax instance accessible from the web, with microsoft lifecycle services.
https://lcs.dynamics.com/
you can also ask your new Company to download a demo VM for you. It's available on the Customer and on the Partner Source.
https://mbs.microsoft.com/customersource/northamerica/AX/downloads/service-packs/AX2012DemoToolsMaterials
Unfortunately, besides MorphX, the native IDE in MS Dynamics, and Visual Studio(for C# dev), you don't have much of a choice.
However, there a portal called 365 Talent portal, where you can register as a freelance MS Dynamics Developer and request for an access to the Dynamics Learning Portal (DLP).
Finally , after your access to the DLP is granted, you can play around with some VMs(with AX installed), read documentation, etc.
I am aware of of the infamous Considerations for server-side Automation of Office from Microsoft and it clearly lists products from the 2010 suite.
However, today I was made to believe by an IT ops techie that Office 2010 does not suffer from the issues mentioned in that article and can be used without issues within a server environment. I have been unable to find any reference or supporting doc that would substantiate the claim. (I will follow up with him on this, however he must have been referring to some other server side technique) My gut tells me he was smoking his socks!
Is there an Microsoft based solution for server side automation for Office 2010? If yes, can you please provide a relevant link that supports the claim.
(I am not looking for a Spreadsheet Gear, OpenXML SDK, OpenXML etc. related answer)
If he's referring to automating the Office 2010 client on the server, he continues to be wrong. If he's referring to newly available functionality on the server that automates some Office document processing, he's right. It's likely he's referring to the later and has just skimmed some marketing material and came to a conclusion in his head that Office client can now be a headless automation server or some such thing.
Office 2010 on the server side came with a number of Application Services that work with SharePoint 2010 that significantly assist with server-side processing of some Office documents and functionality. In particular:
Word Automation Services
Excel Services
InfoPath Forms Services
and Visio Services
It would seem that the techie was not that far off and there actually was some validity to his claim. I refer you to Windows HPC Server 2008 R2 which deals with High Performance Computing (so this does not apply to your run of the mill type workbooks that I guess most people deal with) . This does make sense considering the company I am working at is with the insurance sector. Note: this only works for for a High Performance Computing server
I refer you to a Microsoft techincal whitepaper
Windows HPC Server 2008 R2 now enables running multiple instances of Excel 2010 in a Windows HPC cluster, where each instance is running an independent calculation or iteration of the same workbook with a different dataset. Many complex and long-running workbooks run iteratively—that is, they perform a single calculation many times over different sets of input data. These workbooks might include intensive mathematical calculations contained in multiple worksheets, or they might contain complex Microsoft Visual Basic for Applications (VBA) functions.
...
workbooks may need to be modified to work with this solution. When Excel 2010 runs on the server, it does not support user interaction. Windows HPC Server 2008 R2 includes a comprehensive pop-up manager that can handle occasional dialog boxes and pop-up messages, but it is not designed to support interactive Excel 2010 features
There is also another doc: : Accelerating Excel 2010 with Windows HPC Server 2008 R2: Building VBA applications and workbooks for a Windows HPC Cluster which goes into detail as to how to building Excel solutions for a HPC server.
Your IT OPS techie should send you a link to any information that suggests this. You should then post the link here.
That way, we can try to get the link corrected. Office hasn't stopped being a COM-based desktop application. Do not attempt to automate it in a multithreaded (server) environment.
Your techie may be thinking of the fact that there are now web versions of some of the Office products.
I think everyone has proven your colleague has his wires crossed.
If the problem you are trying to solve is "how do I automate the generation of Word Documents?" then check out www.intelledox.com these guys have a .NET based Doc Gen engine which consumes data from anywhere, web service, XML etc to create documents.
They are then delivered somewhere like in an email, into an ECM system, SharePoint etc.
Means you can stand up an engine that creates standard letters and correspondence etc.