I have some event handlers which are tracking list items in my SharePoint lists. I would like to Audit the use of these in an external database (SQL 2005) outside of SharePoint.
What is the best practice for doing something like this? I can't find many examples of this being done but it seems like it would be something that is done frequently. Would love to get pointed in the right direction on this one!
Normally to get a DB connection in a .net app, I'd create a connectionString in the web.config. Should I be modifying the web.config for the web application that the code will run on?
It would be handy to be able to use LINQToSQL for my DB inserts/updates - is this possible from within SharePoint code?
Thanks
I am not sure I understand your auditing question fully to comment on it.... There is built in auditing functionality that you can utilize if it meets your requirements. Ted Pattison discussed this in an Office Space column a while back.
In regards to you other questions...
You can put a connection string in your web.config, we do this often. There can be concerns in SharePoint manually updating the web.config due to the fact you can have multiple servers in a farm and you don't want the web.config to get out of sync. SharePoint has a SPWebModificationClass you can to automatically update the web.config. I have run into issues with this using FBA (see this SO question).
You can use LINQtoSQL for your database access. However, if you are using SP 2007 instead of SP 2010, you will need to update your web.config to reference all of the proper DLLs. You can what references are required by looking at an ASP.NET 3.5 web.config and comparing it to SharePoints. I am sure there are links on how to do this also.
Hope that helps get you started
Related
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.
WSO2 Identity Server 5.0.0
I am wondering what the full path of SQL queries would be if i wanted to create and update Service providers via SQL queries. It's more than adding to the SP_APP table as a newly inserted entry by that means doesn't show in the UI. I was looking through the identity-core code and got a little lost, since it seems to abstract out some intricate registry stuff.
Anyway, I'd love to know how I could navigate the database to look at stuff by these means.
I would suggest moving your WSO2 IS completely onto SQL Server. You can then see all the tables and scripts that are run against it (using something like QueryProfiler). To do this, follow the instructions: https://docs.wso2.com/display/ML111/Setting+up+Microsoft+SQL.
Note that at the end of the document you must run two scripts (not just the one they show):
<PRODUCT_HOME>/dbscripts/mssql.sql
<PRODUCT_HOME>/dbscripts/identity/mssql.sql
I have to admit that the documentation on WSO2 IS is not very good or complete, but they have been good at answering questions. SQL Server was hard to set up as some of the steps were old (as you see they reference SQL Server 2005), but if you know your way around SQL Server pretty well, you can figure out the minor things. The largest issue was the second .sql script that needed to be run.
That should set you up well enough to see what is being called when set up Service Providers, or anything else that goes into the database.
I have created a functioning LightSwitch (Visual studio 2012 Pro) application...
Now it's time to publish! The only problem is that I can't seem to figure out how to change the schema name to something other than dbo.
That is, I don't want the output tables to be dbo.XXXX, I want them to be my_schema.XXXX instead.
Also, note that the database is on SQL Server 2005.
Does anyone have suggestions on how to achieve this?
Thanks!
Update: Sorry for not being specific. I don't want to change the schema for existing tables in my database. I want my LightSwitch application to use the new schema. I don't mind publishing it and then modifying the schema on the tables, if I can then somehow also modify the LightSwitch application to use the new schema. But ideally, there would be a way to tell LightSwitch to use a different schema when it publishes.
For those who don't know what LightSwitch is, it is a Microsoft .Net Rapid Application Development tool for SilverLight business applications, and is built into Visual Studio 2012. My application is written in VB.Net
You can't change the schema name for an intrinsic database (the database that is created with LightSwitch). Maybe you'll be able to in V3, but you can't currently do it in V1 or V2. To achieve this, you'll have to create the database in something like SSMS (SQL Server Management Studio, then attach to it as an external data source.
Seeing as you've already done all the creating in LightSwitch, you could publish it as is, then attach to it as I mentioned above. I hope you don't have screens created, because unless you want to manually edit all of the lsml, you won't be able to use the attached database in any already created screens.
Any time you need to do something "out of the ordinary" with LightSwitch's database, you need to create it outside of LightSwitch, then attach to it. Why? LightSwitch was originally created with the idea in mind that the users didn't need to know anything about SQL Server.
I am busy developing my own application, it uses a sql server database and it is connected through an entity framework. I use store procedures to insert, update, delete, select from my database.
The app works perfect on my machine even when I publish it. But my problem comes in when I try to install the app to my friend’s computer. It crashes and does not start because it cannot connect to the database.
Is there a way to publish my app with the database, without importing all the tables, store procedures and database into my friend’s pc? I just want to make it so the user just has to install the app and it works.
Your app relies on the db to work, so if you want to put it on your friends PC then you need to make the DB available somewhere, whether it be a local copy or a copy stored on a server somewhere running SQL.
How are you storing your connection string? Is it hard coded in the app or are you utilising the app.config file? To do what you're trying to do you'll need to put the connection string into the app.config file, so you can change it depending on the installation.
either that or
if you want to run your app without data, put a demo flag or something into the app.config file. Put some code into your app to check this value, if it's true then bypass the SQL code and maybe supply some demo data which is hard coded.
Does this make sense?
You could use SQL CE, but you may find it a little more difficult to 'design' your database in it if you are more used to working in SQL Server.
Have you considered SQL Server Express as an option?
On the connection string issue, you can now get the data connection wizard that Microsoft use in Visual Studio via Nuget; this makes adding a way to dynamically configure connection strings on your clients machine much easier.
Lastly, connection strings for the entity framework are different from standard SQL connection strings. Make sure that you clearly understand the differences before you start trying to configure them programmatically. Julie Lerman's excellent book on the Entity Framework explains the differences well.
So I've created an Access Project for one of my users so he can connect to a reporting database. The .adp project connects to the DB and he can query data to his heart's content. The problem is, no queries can be saved. Whenever he opens the project, he is presented with the following error:
"This version of Microsoft Access does not support design changes with the version of Microsoft Sql Server to which your Access project is connected. See the Microsoft Office Update Web site for the latest information and downloads. Your design changes will not be saved."
Again, this is Access 2007 and Sql Server 2005. My googling efforts - which are coming on a day when I seem to be especially stupid - keep bringing up information regarding this error for Access 2002/2003 trying to connect to Sql Server 2005, which is clearly not my problem.
I'm seeing that one can connect to Sql Server with the normal Access databases (.accdb in 2007 or some such), but I'm seeing mixed information regarding whether I want to do this or not. And since I can't get a copy of Access 2007, I can't really test this (topic for another time).
Before I do down that road, I'd like to get to the bottom of this one. Anyone have any suggestions, useful links, or useful knowledge? Or an older developer who knows the answer that is no longer needed, so I can eat him and absorb his knowledge and powers?
The account being used to connect to the DB was only a db_reader. I changed it to DBO and that fixed the problem - user can now create and save queries, and sleep at night knowing that tomorrow will bring a new day with new querying possibilities.
I'm not super crazy about this though the reporting database has been set up on a separate install/server from impotant App databases. I'm not worried about the user (or anyone on his group) blowing anything up. I'd like to understand why this is, and don't (outside of the obvious - reader is read only! I didn't expect that to extend to work in Access), and will try to do so at a later time. One of the unfortunate aspects of working at a dev shop focused on internal app development is, "well, it's working, you have other things to see to".
I am not sure if I can be of help here.
But you can have a view inside Access which connects to SQL database and use that view.
Alternatively, you can go the other way. Have a DB project with SQL Server & create a linked server to MS-Access DB.
Did you try linking to the tables through an ODBC connection?
CodeSlave, I did not. The attitude from higher up is "it's working, move on". I'm not sure the boss really wanted to go down that road anyway, but it's a moot point. I should probably try granting the account dbreader and dbwriter access and see if that accomplishes the same thing, but it being dbo isn't really a huge deal. Or rather, it's not a big enough deal that The Powers That Be want me to seek an immediate change.
I was going to try linked tables until changing the SQl Server account permissions "fixed the problem" (quotes very deliberate; it feels like one of those solutions you arrive at without a proper understanding of what it worked, which vexes me).