My new project requires me to create some 12 SQL tables and build some web parts in SharePoint 2010, to perform CRUD operation on the tables. One main table has around 25 columns and the rest of the tables has 2 or 3 columns and some are just join tables.
The main requirement is the when someone adds or changes the data in the tables it should not be available to everyone. A manager must approve the data before it is updated in the table.
I don’t have much experience in SQL or SharePoint for that matter, so can someone let me know how this can be done.
And is web parts the best way to do the CRUD operations, or can I use BCS which I feel is easy?
I would look at Access Web App. In SharePoint 2010 it will create lists as underlying data "tables", you can create workflows on these lists.
If you have limited experience in SQL or SharePoint this will offer you a GUI driven solution with very little or no coding requirements.
Access Web Apps offer a more versatile BCS-type solution. It is more bulky, but it is far easier to develop your solution and you can still leverage your SharePoint permissions and workflows.
Related
I'm building a talent management CRM application and I'm having trouble choosing between a SQL or NoSQL database for my data.
The application will only have a few 'core' entities (Person, Job, Company, Interview), and will rely heavily on 'tagging' of those entities. You can add Tags and Notes to a Person, a Job, a Company, and then sort/search data by those tags.
What I learned about NoSQL is that I can just have a Person object (document) with an array of Tags and Notes, where in SQL I would need separate Tags and Notes tables and construct joins to gather all my data for a Person.
Could anyone give me some pointers on what would be the way to go for my particular scenario?
Thanks!
Our ERP system is based on UniData (NoSQL), it is okay for performing the standard tasks needed to do business like entering in customers, creating sales orders, invoicing etc. But when it comes to creating reports that were not originally foreseen it is quite cumbersome. The system only lets you create reports off of one table, if you need data from another table you have two options: 1. Create what is called a virtual attribute for every field you need to look up from a different table, Or write a UniBasic program to retrieve the data needed.
To meet most of our business needs on the reporting front it is more beneficial for us to export the Data to SQL and then perform reports in SQL, the result is the reports run quicker from SQL and most of the time a reporting tool can be used to create the reports - this can usually be performed by a power user as opposed to someone that has to have quite a high level of programming abilities to just build a report.
It would have been nice if it had already been in SQL in the first place.
But maybe some other NoSQL database has better functionality than UniData, that said too usually 3rd party support for NoSQL database engines comes at a higher premium because there are less specialists available than 3rd party support for SQL engines.
I am working on a project having a large scale database with several stored procedures and I need to use the data in SharePoint 2013, the database is in SQL Server 2008 R2
According to my understanding I have two options:
1) is to create a Web service, using entity framework to interact with the database and most probably will use WebAPI. My logic will be in Stored procedures or DAL layer.
2) Secondly, I did a little research and got to know about the Business connectivity services provided by the SharePoint 2010/2013 as I am working with 2013 so I will be using visual studio 2012. Now learning more about the BCS I understood that I can map each table as a content type and then somehow define relationship. Anwyay, implementing BCS is a separate issue which I think I will somehow manage.
My question is how am I going to import/include my stored procedures? and if not stored procedures then where will I write my queries to get the data from the BCS?
Please direct me to right direction. Thank you.
Using a custom BCS connector you implement the way you want to retrieve the data from the DB (directly in C#), so you can query directly the table, or stored procedures.
If you want to try a BCS connector to create an external content type to use in SharePoint, take a look at my blog. My example is related to indexing sql data for the search, but the way it's done in SharePoint is creating an external content type, and this content type is the one that you index. So you'll find useful information on how to create that BCS connector.
We're just starting Sharepoint development, and one of my first tasks is to build a data collection tool. It will be used across multiple sites, so there will be an admin area, and each site will pull in it's related questions, and record the data. I've gone through a bunch of tutorials on development, and have a fairly good idea of how to start. I just want to make sure I understand one thing. Do lists basically take the place of your database? If this was a regular app, I would create a question table, a link table that tells which questions are connected to which site, a table that stores the answer, linking to the site and question table.
Is this the basic pattern you follow, or should I be doing things differently for Sharepoint applications?
If the thought is to use an external databse, can anyone point me to some info on this?
In our Sharepoint project we stared with Lists. It was good to some point - till DB had only few relations between data. After adding tables and relations performance falls a lot and we had to switch to use standard DB in MS SQL Server. So I recomend to use DB.
Disadventages: you cannot use sharepoint controls to edit/view data and cannot restrict access to data from sharepoint level
Adventages: much faster access to data
Is there a way to show table relationships as can be done in Access? Consider two tables:
Services
serviceid
application id
Application
application id
application name
I have already set up the diagram.
When opening the table service id I want to see the related application details like in Access.
Is this possible?
First of all, you an always use access to connect to SQL Server and see relationships through it.
The built in database diagram feature will also show relationships, as you describe. You can find it under the database in question in the diagrams node.
Here is an article about different options to produce an ERD.
Update:
In order to see results, I would suggest using access to connect to SQL Server, as described in the link above.
The SQL Server GUI does not have this facility, and if you want to see results from several tables you need to write the SQL queries that will generate the wanted data.
You could also create a VIEW:
CREATE VIEW ServicesApplication AS
SELECT S.ServiceID, S.ApplicationID, A.ApplicationName
FROM Services AS S
LEFT JOIN Applications AS A
ON S.ApplicationID = A.ApplicationID
That way you can always access the coupled data easily by manipulating the ServicesApplication view instead of the separate tables.
SQL 2008 doesn't have anything built in to provide that functionality. Almost sounds like you're looking to trouble shoot an application by looking at database entries...if thats true I'd recommend learning tsql well enough to write these statements as you need and not rely on another application to provide a visual interface. heh, if I'm completely wrong with that, ignore me :)
If you still want the 3rd party application route...I beleive TOAD has that functionality within it, though I've never connected it to a MS SQL 2008 server before. There are other third party applications out there that will provide this functionality, though I imagine they aren't all free. If you're looking for a free solution and already have Access going, Oded probably has the best idea here...connect MS access to the SQL 2008 server (linked tables) and use MS access to provide the features you want from ms access :)
All our applications rely on a certain amount of client data i.e. Lookups for comboboxes, users, roles, user-roles...
We currently use a spreadsheet to map the data and generate insert scripts that are then imported into SQL server. The has seemed to work for us but it is very difficult to update and maintain when there are a lot of changes going on (excel is not good at merging data) and it is slow when there is a lot of data.
I am sure this is a common problem and would to hear how others have approached it so we could borrow some ideas and improve our process.
Excel rocks for importing data. You can quickly edit, troubleshoot, and it has lots of options to organize data.
Several developers at my company tried to phase out the Excel data import sheets, but they all failed (one after 6 man-months.) It not always worth the effort to build a specialized data entry web site or windows app. :)
Infopath and SharePoint? (just throwing it out there. It takes some skill to setup well which I would generally doubt that you have at your company)
You will probably have the same issue with any disconnected file based approach. My suggestion would be to build a web page with your lookups that will change and give your customer access to it. Let them maintain the data.
I suggest SharePoint as well. Specifically, Windows SharePoint Services 3.0. It's pretty simple to get it up and running and it's included with Windows Server. You can easily create a custom list (you can even import it from Excel) and best of all, you can link it to Outlook and do mail merges on it. Great stuff.