I have a WCF Data Services service that exposes a set of ICD codes. The primary key for the underlying table and the data set that WCF provides access to is a varchar or string in C#.
The service works properly if I have a query like this:
http://somehost/someService.svc/IcdSet('001')
If, however, the ICD code happens to have a . in the identifier as many do, the service fails. Here's an example of one that won't work (IIS gives a 404 - Not Found response):
http://somehost/someService.svc/IcdSet('001.1')
So the question is how can I escape the period or properly pass it to WCF Data Services? It must be interpreting it as a different type of filter condition.
Note: The code for the underlying class seems irrelevant to the question but I can provide it if needed.
Edit: My guess at the moment is that IIS is trying to find a file that ends with .1') which is then producing the 404 error. But how can I tell IIS that it shouldn't be looking for files as these are all data queries?
check this out http://blogs.msdn.com/b/peter_qian/archive/2010/05/25/using-wcf-data-service-with-restricted-characrters-as-keys.aspx
Also might be of interest if you're using .Net 3.5 http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=5121
Related
I have a ASP.NET Web application. The application connects three different databases. So I have defined three connection string in web.config with different database name and credentials.From the application code I am pointing to the relevant connection string and firing stored procedures. Sometimes the procedures are hitting the wrong database. My guess is that as .NET cache the web.config, somehow the framework is returning the wrong connection string from cache and the application hitting the wrong database. I have checked the application code and found it is pointing to the correct connection database in all cases. Is this happening due to web.config chancing? I cannot identify the root cause of the problem. Please help.
If you are using EF to connect to the database, you have to close the scope of the context and then initialize a new context with the required connection string and then use that context to execute the SP.
I don't think this is an issue with the caching !
If there is only one DAL which connecting to different databases then it is a high chance of application mistake somewhere.
Possible solution, as we have no idea of how is you data access code looks like, is to create 3 different DAL and in each of them realize logic to work only with specified connection string.
For example create 3 different classes inherited from DbContext with different connection strings in constructors.
I am just reading up on OData from here.
http://msopentech.com/odataorg/introduction/
Sorry, I am getting a bit impatient.
I just have a simple question for now before I go through the rest of the material. Which of the two options describe OData?
I understand it provides a protocol (much like SOAP or XML/Json over HTTP or XML-RPC) to transfer data from services over the web to clients. What I am intrigued by is that it also helps query that data, which is a great problem to solve as it help reduce payloads that you usually encounter when querying large data sets with XML/SOAP web services or other means (XML over Http, Json over Http, RPC responses, you name it).
Option A
Does oData get all the data to the client, use some client-based storage (like HTML 5 local storage for desktop browsers) to store it, and then query the data on the client using an in-process API?
Or
Option B
Does it provide an XML-based syntax for translation Linq like expressions and getting only the relevant result sets (filtered, ordered, whatever else) stuff from the server?
It's funny how when you type your thoughts, you end up solving your own problems. I think just typing the question has given me the answer. Option A sounds preposterous for so many reasons:
1) If it's a data-centric protocol, it has to not care about what type of client or consumer will want the data, so it cannot have any affinity to client or the capabilities (caching on client side) of the client.
2) It is a data-centric protocol and hence does not prescribe how data must be read or offer any tools on the client or server sides. It merely prescribes a data format, I would imagine.
It has to be Option B. Still, I just want a confirmation or correction.
Yes, it is Option B.
You could obviously write a terrible implementation of a client that would download ALL the data and then filter and show data based on client-side logic. But that would be rather silly.
The way you "write" your queries is quite well detailed in OData.org's "URL Conventions" page, typically something along the lines of: http://someserver/odata.svc/Customers(Location eq 'New York')
I don't know if this is common or something but I wanted to check. So I am building a site on an iis7 server and coming across a weird problem. Whenever I have 2 clients accessing the site it seems they are sharing info. Here is an example, when one client does a search for a particular item, the other client goes to the search page and see's the results of client's one search results. I am using a global class to store this information on my code behind.
So here is my question, my understanding of servers was that if two clients accessed the server they were running on different instances of the site, meaning that even if I have a global class in my code it would be as if two machines were running it. Am I wrong in this understanding?
Also are there settings in IIS that I need to change for this to work?
In asp.net, you can use Session variables which are unique serialized token type things stored in server memory. You can store html form info in these sessions so another page on your site can read it.
The syntax in your MVC controller action to create a Session would be:
Session["MyFormData"] = someObject;
http://msdn.microsoft.com/en-us/library/ms178581.aspx
I want to test the results from a WSDL service in a browser like IE9 or FireFox. I know that I can view the WSDL XML, but I want to test the return results of an endpoint called GetEmployeeById that accepts a parameter called Id and returns a class. I am assuming this is all serialized to XML, so a browser would be a good fit for testing this. Is this possible?
In case you are using Visual Studio for .net development, I think something much better than a browser probably would to use:
wcftestclient <url>
which can be called from the command prompt and is part of the tools from visual studio.
The tool will help you to build and receive complex objects and see the results already serialized.
internet explorer let's you make a request with simple string parameters if the WSDL provides enough information.
If you haven't seen it, then probably the WSDL is only for discoverability reasons, probably just points to another service in a different transport protocol, not port 80, if the service is not on port 80 you won't be able to use your browser.
You have another more complex tool called FIDDLER that you can format any kind of http request, as well as receiving any kind of requests, like json for example.
You can use this URL to test WSDL endpoints, send request and see response.
I have one type provider that connects to the network to retrieve data.
And produce (the fiction we call) 'static type' through type providers mechanism.
Of course, I might not always be connected. I might be raging in a private jet with satellite connection down.
Has anyone experience building an "offline type provider" which take (somehow) a type (from a type provider) as an input, stores its definition on disk, and provides you later with said type definition for easy access while on your way to Koh Phangan ?
Since types are not allowed as parameter to TP, I was thinking in providing assembly name + type name to be offlined.
You can enhance your original type provider to work both in online and offline modes. I.e. provider tries to connect to data source and fetch schema, if successful schema is cached on disk (in some format that provider can understand). After that provider exposes types using schema information on disk. If for some reason connection to data source is not available - provider checks if cached schema exists and if yes - uses it. For example standard type providers (LINQ2SQL or EF) allow you to specify schema file that can be used if direct connection to database is not possible.
This is a tricky aspect of writing F# type providers. But I think the main problem is that when you're developing in a private jet and you're using type providers to access some external data source, then you won't be able to access the data.
Schema caching -
If the type provider supports some form of schema caching (i.e. by storing the schema in a XML file like LINQ to SQL mentioned by #desco), then you'll be able to write some code and compile it, but you still won't be able to test the code. I think this makes schema caching less useful for the private-jet scenario. However, it is useful in scenario where you build code on a build server that does not have access to the schema.
Local data - For the private-jet scenario, you probably need some sort of local data (or a subset), to be actually able to test the code you write and then you can often point the type provider to your local copy (database, CSV or XML file etc.).
Meta-provider - I think the idea of having meta-provider is pretty cool - it should work to some extent - you would be able to cache the schema, but you probably wouldn't be able to cache the data (perhaps the values of properites, but I guess methods would not work). I think it should be possible to just pass the name of the provider to mock as an argument to your meta-provider. Something like:
type CachedDB =
SchemaCachingProvider<"FSharp.Data.TypeProviders.dll", "SqlDataConnection", "..">
I'm not aware of any plans for doing something like this, but if you started, I'm sure the FSharpX people would be interested in looking at it :-).