I am at the end of my nerves trying to find this.
I am in progress of migrating SQL 2005 DB's to 2012 and I cannot find the connection string in the websites code. Its an old ASP page and the only ref to the connection string is at the top of each page with the following.
Set OBJdbConnection = Server.CreateObject("ADODB.Connection")
OBJdbConnection.Open Application("ITRC_ConnectionString")
This website is contained within an APPS folder and within the apps folder is a page called appvars.asp. All the other websites in the APPS folder use this page for their connection string and therefore I can easily migrate these but this one chuffing website isn't listed.
Anyway my question is where are the places I should look to find this connection string. There must be standards or something I can look for that will tell me.
As much as I hate to admit this we have 2 webservers and the site I was looking at was inactive doh!!! I found the correct site which was re-done in asp.net and repointed the connection string.
Related
I have a site that was recently moved to a new server. It seems as though if a link on the site, or entered directly in the address bar, include a query string such as :
https://www.web.site?id=5314&type=course
It would automatically duplicate it to be:
https://www.web.site?id=5314&type=course&id=5314&type=course
Notice the duplicate url parameters?
id=5314&type=course&id=5314&type=course
I've combed through my code and I cannot determine what's causing this. Is there anywhere else I should be looking?
This is a ColdFusion site running on a Windows server.
I am trying to fix several web pages originally designed for older versions of internet explorer to render fine on internet explorer 11. With the following meta tag, the page looks almost okay but still one part of the page is broken.
<meta http-equiv="X-UA-Compatible" content="IE=EmulateIE9">
While checking in the debugger tool, I see that the document mode is correctly set to 9. But the user agent string is showing as Default. When I change the user agent string to Internet Explorer 9 using the debugger tool, the page renders as I want.
I did a lot of research to find how I can set the user agent string using code or the doctype directive and so far no luck. At this point, I almost think that it is not possible to set the user agent string using code in IE11.
To summarize, what I am trying to do is to set the document type to "9" and the user agent string to "internet explorer 9" using code.
IE11 does not expose a public API for changing the IE user agent string using JavaScript. (You can temporarily change the user agent string using F12 tools.)
There is a set of registry settings that used to affect the navigator.userAgent property, however, these settings are no longer used during the HTTP negotiation process. (Also, it's probably worth pointing out that the version vectors mentioned in this article require conditional comments which became unsupported starting with IE10.)
The user agent string has become an increasingly difficult feature to rely on. Solutions requiring specific user agent strings should be updated to rely on more modern approaches.
You should take a look at the legacy code and look for the part that's sniffing the user-agent string. It's possible you might be able to fix it with only minor surgery.
Hope this helps...
-- Lance
I'm writing a website for a local club of ours. I've got all the site written in ASP linked to our backend SQL server and it works lovely. I want to create player profiles now. Normally I would use "(a href=playerdetails.asp?ID=1) Player 1 (/a)" then in the ASP section of the page use strsql = "SELECT * FROM Players Where ID=" & request.querystring("ID").
However, this is where my problems starts. To save money for the club, I am also hosting the site for them on my private domain. We have registered there domain and instead of paying for hosting, we're just redirecting the traffic via the domain registers URL forwarding, using masking. Therefore instead of the URL saying www.mydomain.com/club/ it says www.club.com.
Thus the original question... Can I use request.querystring with the setup we have? If not, is there a way around it as the club doesn't really have the budet for a hosted site with SQL in the backend.
Thanks in advance,
Paul.
PS <'s in the link replaced with ('s to display correctly.
A couple of things:
URL Masking uses frames to hide the actual URL. You can still use query string values in the URL, however you will not see the URL in the address bar change, because it will always be www.club.com do to the URL masking.
http://en.wikipedia.org/wiki/Domain_Masking
Second you are opening up your site to SQL injection attacks:
NEVER trust user input
NEVER use Request.QueryString or Request.Form in SQL states without filtering out bad characters and keywords.
http://en.wikipedia.org/wiki/SQL_injection
I'm using Report Builder 3.0 to create a report for use in SharePoint 2010. SQL Server 2008 R2 is the back end with Reporting Services in SharePoint Integrated Mode. One of the cool features of Report Builder 3.0 is the use of a SharePoint List as a data source, the setup for which is very straightforward--just give it the URL for the SharePoint List as the connection string and it works.
I eventually want to package this site as a Site Template including the report that lives in it, which means that the URL will need to be relative instead of absolute. So for example instead of this:
http://mainsite/subsite1/lists/mylist
... I need to specify something like this:
mylist
... so that when I package this as a Site Template and create a new site based on that template, the report will work with the new site's list instead of pointing back to the original site's list URL. I've tried "mylist", "lists/mylist", etc.--everything short of specifying subsite1/lists/mylist--but nothing has worked so far except for the full URL.
Is it possible to use a relative URL or some other method so that the connection string won't have to be manually changed in the report every time I create a new site based on this site template?
Edit: I misunderstood what needed to go in the data source's connection string. It's not the URL to the list but rather the URL to the site that goes in the connection string. The concept of the question remains valid though--need to dynamically set the connection string of a data source that points to a SharePoint list.
After brainstorming with some co-workers we figured it out. The key is to use an expression for the connection string. Using my original example the goal is to get this:
http://mainsite/subsite1/
... in the connection string but without hardcoding it--make it dynamic based on where the report lives so the report can be packaged along with the rest of the site as a site template. The expression I ended up with is:
=Replace(Globals!ReportFolder, "Reports", "")
The report lives in a library called "Reports", so Globals!ReportFolder returns:
http://mainsite/subsite1/Reports
The Replace() function then takes out the "Reports" part of the string, and the result is the connection string I wanted.
Things to look out for:
You can't test the expression while you're building the report. I had to hardcode the site URL into the connection string so the designer could populate the list of lists when creating a dataset based on that data source. Otherwise it doesn't show the available lists and you have to manually type everything. After designing the report I changed the connection string to the expression, and when deployed it worked.
When testing make sure to refresh your browser view instead of the little refresh icon in the report's task bar. Seems like the report's built-in refresh only grabs new data but uses the rdl file it already has on hand, whereas refreshing the browser forces it to get the latest copy of the rdl as well as latest data. That's probably self-explanatory, but it caused me some confusion for a few minutes when it didn't look like my design changes made any difference, so hopefully this will help others not go through the same confusion.
I have a Search web reference (from a Search Server 2010 express install) in a vb.net application that is utilizing the QueryService Class to search a production Sharepoint foundation 2010 site.
At a previous point in time, we had created a proof of concept on an entirely test system that has since been turfed. From my recollection on this test system when documents were uploaded as a specific site content type (that inherits from document) and metadata was provided, we could search for specific metadata by making managed properties for each, and search results would be returned as documents (with the isdocument flag set to true). Viewing the document then became simple, as we could simply use the filename and path to display the stored file.
Now we are developing a production system and we have encountered a new behavior, where these results now are returned as aspx results such as
http://digitizaton/Company/Client Documents/Forms/DispForm.aspx?ID=1703
This of course makes it terribly difficult to locate and view the document, we can extract the Title which will then give us the name of the file with no extension, but that hardly helps, as the FileExtension data is aspx, not the documents file extension, so we don't have a full filename. We could display the page returned as a result, but would much prefer the document itself.
I've made a test document library, with just bare bones setup, (not using the site content type, or site columns) and uploaded some documents on the same site, and they are returned in the same fashion, so I don't believe the document library, or content type are the issue.
With a fairly limited understanding of both Sharepoint and Search Server, I don't know if this is a setup issue with the search service itself, with the site configuration, or with the querypacket I am sending. We also have a third party application (Knowledgelake) installed on the server that ties into sharepoint which could have changed configuration somewhere as well?
I don't think the query packet has changed since it was working in the proof of concept, other than the custom data column names. I will provide it here in case there is something glaringly obvious to an external reader.
<QueryPacket xmlns='urn:Microsoft.Search.Query.Document'>"
<Query>
<SupportedFormats>
<Format>urn:Microsoft.Search.Response</Format>
</SupportedFormats>
<Range>
<Count>0</Count>
</Range>
<Context>
<QueryText type='MSSQLFT'>
SELECT Filename, Title, FileExtension, IsDocument, Path from Scope() WHERE ""Scope"" = 'Department1' AND CustomData = 'X' --
</QueryText>
</Context>
Any guidance would be incredibly appreciated. If I have not provided some relevant information, please let me know and I can track it down.
Thanks everyone
So now I feel like an idiot, I've searched for hours with no luck, and literally seconds after composing this post, I find the nugget of gold I've been searching for.
It appears that our primary file type, PDF, has a known issue with Sharepoint 2010, as shown at the following site.
http://www.sharepointsharon.com/2010/03/sharepoint-2010-and-adobe-pdf/
and further to that, this registry entry setting is required to link it all together
http://www.mossgurus.com/adnan/Lists/Categories/Category.aspx?Name=SharePoint%202010%20--%20Configuration