How can we get a list of start addresses added in a Sharepoint content source programatically ? The code which need to achieve this will be running on different server than where sharepoint is installed so i am looking for a solution where we can query sharepoint database to get this list.
Never query the sharepoint database directly. Even a simple select statement an cause a read lock, potentially creating havoc in your farm.
By using the database directly you are NO LONGER SUPPORTED, meaning that if it does go belly up and you call microsoft for support, they'll send someone from consulting ($$$$) or ask you to go back to the last known good configuration (i.e. a backup of your sharepoint databases from before the point you started accessing the database directly...)
Create a web service that uses the sharepoint object model to get this list, then deploy it to the sharepoint machine, then have your external app use that service.
Related
Currently I am creating app that needs to store and pull data from database by multiple users.
Since I do not have much knowledge in database, MS Access, and MS Sharepoint, I would like to know if it is possible to use share point as database for my iOS application, which implemented in pure swift code.
Any one with knowledge in this field please help me by providing advice on if it works, and, if possible, how can I successfully implement this.
Thank you for all the helps.
I don’t see why this would not work. As long as the SharePoint tables follow the rules for Access, then you can place the ms-access application on each desktop. Anytime “any” user of that application updates or adds records, then all other users will “eventually” see the updates. So in this setup, the desktop users can in fact “run” the application “off line”. The instant such users get Wi-Fi or a connection (or always have one), then the data is synced in real time.
The above setup takes no coding and is part of the Access system which supports those SharePoint tables.
As for the iOS and that part of the application? Again, I see little problem since all of the abilities of SharePoint are available as a web service. So as long as your development platform supports standard web services, then your application can interact with that web service to retrieve and update rows of data in those SharePoint tables. As noted, the “sync” to the Access clients will thus reflect any updates to that data.
Since near every modern phone development system supports interaction with web services, then the phone software can do the same. You not have an ODBC like interface, but you can query the data (CAMEL).
The Access desktop client will also be interacting with the SharePoint tables via a web service, but from Access point of view the SharePoint tables (lists) look like any regular SQL like table. So standard VBA code and DAO reocrdsets are supported.
The web services for SharePoint are outlined here:
https://msdn.microsoft.com/en-us/library/ms479390(v=office.12).aspx
And this video shows how you can upload data to SharePoint from Access, and NOTE how the relational table ability of SharePoint is supported by Access. Once that data is uploaded, then Access supports updating of such data as if the data was a local table.
https://www.youtube.com/watch?v=3wdjYIby_b0&list=PL27E956A1537FE1C5&index=2
You can use a single office 365 account at $6 per month for the above, and that single account supports 500 free users. So if you don’t have SharePoint (or don’t want to bother with SharePoint, a single office 365 account also offers these SharePoint services for that one stupid low price of $6 per month – and that account with work with the free Access runtime that that you can use to run the Access side for free on the desktop part of this application.
I am planning to create a desktop app (Java or C# WPF) which would be used by multiple users. The requirements are such that a Graph DB like Neo4j fits perfectly into the scheme of things. I have done some investigations and it looks really good. I am working on the community edition. Now here is the problem. From what I have observed, I am able to make only one connection to the database. The moment I try to make a connection from another instance I get an error. Even accessing on localhost:7474 gives an error.
Is this by design? I understand that in a web App, I can still use a static reference to a single DB instance and work with it. But in a desktop app scenario how do I ensure that multiple users are able to access the database from their apps?
Your app instances can access the same neo4j server through its REST API. There is no need to directly connect to the DB.
Here is a page that shows you how to do that in Java.
I am planning to build an iOS app with using DB(Ms-Sql).
However, people recommends not to access DB from Xcode.
They recommend me to use php or asp for accessing db through a webpage.
I want to know the reason.
Also I am going to use DB only for (view) select line (not insert, update nor delete).
so is it possible to access directly to db for viewing purpose only?
thank you
It's generally bad for an application (mobile, web, any client) to directly have access to any database for security issues. Clients really should not be accessing the database, which is often holding very private/secure data. It opens up vulnerabilities (i.e., sql injection attack).
A set of web services written in php or java or some back-end technology is a more secure, scalable system. These web services can connect to the database and retrieve data. Your iOS application can call the web services and receive the data..for example in the form of XML or JSON.
UPDATED 2010-11-25
A legacy stand-alone application (A1) is being re-created as a web application (A2).
A1 is written in Delphi 7 and uses a MS Access database to store the data. A1 has been distributed to ~1000 active users that we have no control over during the build of A2.
The database has ~50 tables, some which contain user data, some which contain template data (which does not need to be copied); 3-4 of these user tables are larger (<5000 records), the rest is small (<100).
Once A2 is 'live', users of A1 should be able to migrate to A2. I'm looking for a comparison of scenario's to do so.
One option is to develop a stand-alone 'update' tool for these users, and have this update tool talk to the A2 database through webservices.
Another option is to allow users to upload their Access db (~15 MB) database to our server, run some kind of SSIS package (overnight, perhaps) to get this into A2 for that user, and delete the Access db afterward.
Am I missing options? Which option is 'best' (I understand this may be somewhat subjective, but hopefully the pro's and cons for the scenario's can at least be made clear).
I'll gladly make this a community wiki if so demanded.
UPDATE 2010-11-23: it has been suggested that a variant of scenario 1 would be to have the update tool/application talk directly to the production database. Is this feasible?
UPDATE 2011-11: By now, this has been taken into production. Users upload the .zip file the .mdb is in, which is unpacked and placed in a secure location. A nightly SSIS scheduled job comes along and moves the data to staging tables, which are then moved into production through SP's.
I would lean toward uploading the complete database and running the conversion on the server.
In either case you need to write a conversion program. The real questions is how much of the conversion you deploy and run on the customers' computers. I would keep that part as simple as possible, i.e. just the upload. That way if you find any bugs or unexpected data during the conversion you can simply update the server and not need to re-deploy your conversion program.
The total amount of data you are talking about is not too large to upload, and it sounds like the majority of it would need to be uploaded in any case.
If you install a conversion program locally it would need a way to recover from a conversion that stopped part way through. That can be a lot more complicated than simply restarting an upload of the access database.
Also you don't indicate there would be any need for the web services after the conversions are done. The effort to put those services together, and keep them running and secure during the conversions would be far more than a simple upload application or web form.
Another factor is how quickly your customers would convert. If some of them will run the current application for some time period you may need to update your conversion application as the server database changes over time. If you upload the database and run the conversion on the server then only the server conversion program would need to be updated. There would not be any risk of a customer downloading the conversion program but not running it until after the server databases were updated.
We have a similar case where we choose to run the conversion on the server. We built a web page for the user to upload their files. In that case there is nothing to deploy for the new application. The only downside we found is getting the user to select the correct file. If you use a web form for the upload you can't pre-select file name for the user because of security restrictions. In our case we knew where the file was located but the customers did not. We provide directions on the upload page for the users to help them out. You could avoid this by writing a small desktop application to perform the upload for the users.
The only downside I see to writing a server based conversion is some of your template data will be uploaded that is un-needed. That is a small amount of data anyway.
Server Pros:
- No need to re-deploy the conversion due to bugs, unexpected data, or changes to the server database
- Easier to secure (possibly), there is only one access point - the upload. Of course you are accepting customer data in the form of an access database so you still can't trust anything in it.
Server Cons:
- Upload un-needed template data
Desktop Pros:
- ? I'm having trouble coming up with any
Desktop Cons:
- May need multiple versions deployed
As to talking to a server database directly. I have one application that talks to a hosted database directly to avoid creating web services. It works OK, but if given the chance I would not take that route again. The internet is dropped on a regular basis and the SQL Providers do not recover very well. We have trained our clients just to try again when that happens. We did this to avoid creating web services for our desktop application. We just reference the IP address in the server connection string. There is an entire list of security reasons not to take this route - we were comfortable with our security setup and possible risks. In the end the trade off of using the desktop application with no modifications was not worth having an unstable product.
Since a new database server to be likely one the standard database engines in the industry, why not consider linking the access application to this database server? That way you can simply send your data up to sql server that way.
I'm not really sure why you'd consider even suggest using a set of web services to a database engine when access supports an ODBC link to that database engine. So one potential upgrade path would be to simply issue a new application in access that has to be placed in the same directory as to where their current existing data file (and application) is now. Then on startup this application can simply RE link all of its tables to your existing database, plus come with a pre link set of tables to the database server. This is going to be far less work in building up some type of web services approach. I suppose part of this centers around where the database servers going to be hosted, but in most cases perhaps during the migration period, you have the database server running somewhere where everyone can get access to it. And a good many web providers allow external links to their database now.
It's also not clear that on the database server system you're going to create separate databases for each one, or as you suggest in your title it's all going to be placed into one database. Since is going to be placed into one database, then during the upsizing, an additional column that identifies the user location or however you plan to distinguish each database will be added during this upsizing process to distinguish each user set of data.
How easy this type of migration be will depend on the schema and database layout that the developers are using for the new system. Hopefully and obviously it has provisions for each user or location or however you plan to distinguish each individual user of the system. So, I don't suggest web services, but do suggest linking tables from the Access application to the instance of SQL server (or whatever server you run).
How best to do this will depend on the referential integrity and business rules that must be enforced, if there are any. For example, is there the possibility of duplicates when the databases are merged? I gather they are being merged from your somewhat cryptic statement: "And yes, one database for all, aspnet membership for user id's".
If you have no control of the 1000+ users of A1, how are you going to get them all to convert to A2?
Have you considered giving them an SQL Server Express DB to upgrade to, and letting them host the Web App on their own servers?
I'm on a project that is being upgraded from vbscript to ASP.NET MVC. It used Microsoft Index Server to index Word and PDF files on a Windows Server 2003 machine. It simply opened an OleDbConnection using a connection string like "Provider=\"MSIDXS\";Data Source=\"docSearch\";".
After researching a bit, I learned that Index Server is obsolete ("Note Indexing Service is obsolete as of Windows XP. Instead, use Windows Search." - http://msdn.microsoft.com/en-us/library/ms690580) and Windows Search is the successor.
So, in my new MVC app, I'm trying to connect using OleDbConnection with a connection string like "Provider=Search.CollatorDSO;Extended Properties=\"Application=Windows\"".
I have a method that takes in a formatted query and executes the search - here is the query that gets executed using OleDb:
string.Format("SELECT System.FileName FROM SystemIndex WHERE CONTAINS('{0}')", query)
Now, when I call my method in a test class, it works fine (i.e. returns results... myDataReader.HasRows is true). But, when I call the same method from my MVC Controller, it returns no results - myDataReader.HasRows is false - using the same query. My guess is something to do with permissions and IIS not being able to access the index. How can I get IIS to have access to the index? How can I expose the index to a ASP.NET web page? If Index Server is obsolete, and this functionality isn't supported in Windows Search, what am I supposed to use?
I would not change just because it is not supported unless you are having a specific problem with Indexing Service or need a feature from the newer version.
I would get connection string from ISearchQueryHelper
Does the service have the correct permissions? Have you checked the Windows Search 3.0/4.0 SDK?
I see you are on the forum (http://social.msdn.microsoft.com/Forums/en-US/windowsdesktopsearchdevelopment/thread/7b9eead4-d938-42c6-ba2b-2c238a7706f9)
I am not sure Windows Search can really replace Indexing Service for Web sites. For instance, there is only one index called "SystemIndex" which contains everything on the local system. Therefore, how would you limit the results to just a Web site?
I believe you need to use "enterprise search" or "search server", which I have no experience with.
Since the results for both Indexing Service and Windows Search are ADO.NET, the presentation does not change much. The API is different enough that you will need to make many changes. For instance, there is no "scope" in Windows Search. When I changed over my personal "desktop search" application, it took an hour to make the change, but two days to duplicate all the functionality that I had with Indexing Service because of the API changes. I made this change because Windows Search is better when searching for code snippets in my "Code Library"
For standard queries with no regular-expressions or wild-cards or non-standard properties, both perform the same. Indexing Service always retrieves data quicker, but may not perform some queries that are "too expensive". Windows Search can take a long time retrieving the data depending on the query. Typically, these "long queries" are the "too expensive" queries of Indexing Service. "Long queries" can also result from any query that retrieves a property that is not contained in the index.
I am still using Indexing Service for my web sites on Windows Server 2003 and do not plan to make any changes because it is not as easy as I expected and there is no compelling reason to do.
I found my answer here ASP.NET OLEDB code breaks when deployed on IIS7. By impersonating a user that has access to the index.