0

My company is moving towards SharePoint as a base ground for essentially an Enterprise System. Before we go into this (no one knows what capabilities or limitations SharePoint has) I had a few questions.

1) Is there limitations on applications that can be written for SharePoint? Things that you would normally be able to do in a stand alone app that SharePoint doesn't allow. (We will be almost exclusively web apps unless something necessary cannot be done there)

2) Is it possible to view real time data from a database in a presentable form (i.e. a pretty grid)? We've wanted to do something like this before and it was not possible with our current system, but it would be cool if we could.

3) We do a lot of reporting and are struggling with how much data is being pushed into a single string into a CSV (The rate is exponential and more than 5,000 rows is too much). Say we had a grid (I believe it's called a list in SharePoint) that the user could filter in an application, could that grid essentially be copied and pasted into and Excel sheet? We can develop a much better way when writing our own code to transfer data into a CSV, but I would like to know if it's possible out-of-box.

4) Side question; our browser applications in the system we have now have a very difficult time rendering grids. 150 rows takes a few seconds to show up (the queries are done almost instantaneously), have you had grids that have more rows than this in a browser environment and how much of a speed hit did you take if any? I'm essentially trying to figure out if it was a system issue or a fundamental browser issue.

Thanks for any information you can give us as we have been reading as much as we can, if you have any articles that explain specifically about application development for SharePoint please share.

EDIT: What kind of development time would be looking at for a single application? I know this varies A LOT, but say I wanted a simple application that you could see and filter data from a specific table, select a row, change and update it, as well as export capabilities to Excel. We've been in a rapid development system where this would take no more the 30 minutes for a single person, but could we achieve close to that in SharePoint development?

Improve this question
2
  • Is there a target environment that you have in mind - SharePoint version (2010/2013) or edition (Std/Ent) ? There are significant differences in the features that should be considered in answering your questions.
    – Supriyo SB Chatterjee
    Commented Jun 19, 2014 at 14:54
  • We are using SharePoint 2013 with Office 365, I'm unsure of the edition, but I would lean towards Ent until I get confirmation on that.
    – shadowjfaith
    Commented Jun 19, 2014 at 14:57

1 Answer 1

Reset to default
1

1) Since SharePoint is written on top of ASP.NET, you can treat SharePoint from a developer's standpoint as such. Many developers have written ASP.NET pages, silverlight webparts, visual webparts, etc on top of SharePoint.

2) Yes! You can do this through Business Connectivity Services or a Webpart, or an Application page.

3) Any list is exportable to Excel for further sorting/manipulation, etc.

4) It may be a query issue. Are you trying to pull in the bare minimum needed to get the table? SharePoint does a good job of rendering lists and grids so that it's very cost effective (cost being hard hitting) of a query.

Improve this answer
3
  • Thanks for the answers, but I'm confident it's not a query issue as it happens over all applications no matter how small the table being queried or the query itself. If SharePoint does a good job then I would say it was the underlying rendering of the current system we have. It's called MobileFrame and wasn't really designed for what we use it for so it's expected.
    – shadowjfaith
    Commented Jun 19, 2014 at 14:53
  • What is your hardware look like? Network? Disk Usage? Is this SQL Server or Oracle and is the version up to date? All these may be factors that go into the speed of a query
    – Mike
    Commented Jun 19, 2014 at 14:56
  • The speed of the query wouldn't differ between running on SSMS vs in a browser would it? Never really considered that, but they all run quickly in SSMS as well as our windows client, but die in a browser. However, values do appear on the screen that could only come from the query, then after a few seconds the grid finally appears, so it has to be some issue with the rendering in the browser.
    – shadowjfaith
    Commented Jun 19, 2014 at 15:02

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.