I am using SQLProvider from NuGet (https://www.nuget.org/packages/SQLProvider/ v1.1.42) in an F# project to access our MSSQL database.
I am referring to the sample code from here, https://fsprojects.github.io/SQLProvider/core/programmability.html and also the source code tests on GitHub, https://github.com/fsprojects/SQLProvider/blob/master/tests/SqlProvider.Tests/scripts/MySqlTests.fsx.
#r #"....\packages\SQLProvider.1.1.42\lib\net451\FSharp.Data.SqlProvider.dll"
#r #"....\System.Data.Linq.dll"
open System
open FSharp.Data.Sql
open FSharp.Data.Sql.Common
open System.Data.Linq
type SeriesResult = { .. fields .. }
[<Literal>]
let ConnectionString = #"connStr"
type Sql = SqlDataProvider<
ConnectionString = ConnectionString,
DatabaseVendor = Common.DatabaseProviderTypes.MSSQLSERVER>
let db = Sql.GetDataContext()
let test =
[
for f in db.Procedures.MyStoredProcedure.Invoke("param").ResultSet do
yield f.MapTo<SeriesResult>()
]
I need to access results from the call to MyStoredProcedure, but ResultSet errors with error FS0039: The field, constructor or member 'ResultSet' is not defined". I also get this for ColumnValues, and on MapTo (presumably because the type is unknown).
Is there an additional library I should be referencing?
I have: FSharp.Core, FSharp.Data, FSharp.Data.SqlProvider, mscorelib, System, System.Core, System.Data, System.Data.Linq, System.Xml.Linq
Thanks!
(wanted to tag with SQLProvider - but can't!)
One possible reason for this is that the intelli-sense thread probably timed out waiting for a response from the SQL provider.
The stored procs and the set of types to carry the result ResultSet are computed lazily (when you type the .). This is good in one way as it means the provider doesn't introspect the entire database on instantiation, pulling in lots of stuff you're probably not going to use. However it does have the side effect, of needing to do a non-trivial amount of work in the . completion on the first request, we cache the result after that. I believe Microsoft have a metric that says any intelli-sense work should complete in 250ms, but what the actual thread timeout is I'm not sure. With a language like C# and F# hitting a response target of 250ms can be a big ask on large solutions, but throw a database in the mix (even a small local database) this becomes a very hard target to hit.
Quite why it didn't recover and try again until you added the references, will only be known to Visual Studio; Usually however just closing and re-opening the file is enough. In rare cases unload the project from the solution and reload.
Related
I am using FSharp.Data.Sql to access via the Type Provider to a MSSQL database.
No problem with using it, however, I have the feeling that VS is loading all the database when I am typing code which make the visual studio process very heavy (2GB of RAM used compared to a few MB when I am not using it) and very slow.
I thought that
let [<Literal>] connectionString = """Data Source=XXXX;Initial Catalog=XXXX;User ID=XXX;Password=XX;"""
type sql = SqlDataProvider<ConnectionString = connectionString, DatabaseVendor = Common.DatabaseProviderTypes.MSSQLSERVER, IndividualsAmount = 1000, UseOptionTypes = true >
let ctx = sql.GetDataContext()
Have you ever met the same issue? I did not find much in the official doc.
Thanks !
This is likely due to the following issues:
https://github.com/Microsoft/visualfsharp/issues/5929
https://github.com/Microsoft/visualfsharp/issues/5931
https://github.com/Microsoft/visualfsharp/issues/5933
Type Providers (both the SDK and the extensibility point in the compiler) were not implemented in a way that works particularly well for a long-running process such as the F# compiler service. It's ironic since they're useful mostly in editing scenarios, but it is what it is. When these are addressed you can expect most memory usage woes to go away.
It seems that there is no issue in Visual Studio 2019 Preview 3.0.
thanks
I'm just learning F#, and setting up a FAKE build harness for a hello-world-like application. (Though the phrase "Hell world" does occasionally come to mind... :-) I'm using a Mac and emacs (generally trying to avoid GUI IDEs by preference).
After a bit of fiddling about with documentation, here's how I'm invoking the F# compiler via FAKE:
let buildDir = #"./build-app/" // Where application build products go
Target "CompileApp" (fun _ -> // Compile application source code
!! #"src/app/**/*.fs" // Look for F# source files
|> Seq.toList // Convert FileIncludes to string list
|> Fsc (fun p -> // which is what the Fsc task wants
{p with //
FscTarget = Exe //
Platform = AnyCpu //
Output = (buildDir + "hello-fsharp.exe") }) // *** Writing to . instead of buildDir?
) //
That uses !! to make a FileIncludes of all the sources in the usual way, then uses Seq.toList to change that to a string list of filenames, which is then handed off to the Fsc task. Simple enough, and it even seems to work:
...
Starting Target: CompileApp (==> SetVersions)
FSC with args:[|"-o"; "./build-app/hello-fsharp.exe"; "--target:exe"; "--platform:anycpu";
"/Users/sgr/Documents/laboratory/hello-fsharp/src/app/hello-fsharp.fs"|]
Finished Target: CompileApp
...
However, despite what the console output above says, the actual build products go to the top-level directory, not the build directory. The message above looks like the -o argument is being passed to the compiler with an appropriate filename, but the executable gets put in . instead of ./build-app/.
So, 2 questions:
Is this a reasonable way to be invoking the F# compiler in a FAKE build harness?
What am I misunderstanding that is causing the build products to go to the wrong place?
This, or a very similar problem, was reported in FAKE issue #521 and seems to have been fixed in FAKE pull request #601, which see.
Explanation of the Problem
As is apparently well-known to everyone but me, the F# compiler as implemented in FSharp.Compiler.Service has a practice of skipping its first argument. See FSharp.Compiler.Service/tests/service/FscTests.fs around line 127, where we see the following nicely informative comment:
// fsc parser skips the first argument by default;
// perhaps this shouldn't happen in library code.
Whether it should or should not happen, it's what does happen. Since the -o came first in the arguments generated by FscHelper, it was dutifully ignored (along with its argument, apparently). Thus the assembly went to the default place, not the place specified.
Solutions
The temporary workaround was to specify --out:destinationFile in the OtherParams field of the FscParams setter in addition to the Output field; the latter is the sacrificial lamb to be ignored while the former gets the job done.
The longer term solution is to fix the arguments generated by FscHelper to have an extra throwaway argument at the front; then these 2 problems will annihilate in a puff of greasy black smoke. (It's kind of balletic in its beauty, when you think about it.) This is exactly what was just merged into the master by #forki23:
// Always prepend "fsc.exe" since fsc compiler skips the first argument
let optsArr = Array.append [|"fsc.exe"|] optsArr
So that solution should be in the newest version of FAKE (3.11.0).
The answers to my 2 questions are thus:
Yes, this appears to be a reasonable way to invoke the F# compiler.
I didn't misunderstand anything; it was just a bug and a fix is in the pipeline.
More to the point: the actual misunderstanding was that I should have checked the FAKE issues and pull requests to see if anybody else had reported this sort of thing, and that's what I'll do next time.
I'm having some problems with the freebase api. I have managed to put a key to the freebase provider so I don't see any 403 errors, relating quota restrictions. But since I used a google api key, commons is not being recognized when I hit "alt + enter". But while I'm writing, the provider manages to show me data.
[<Literal>]
let FreebaseApiKey = "AIzaSyCOn15-T31Ls"
type FreebaseDataWithKey = FreebaseDataProvider<Key=FreebaseApiKey>
let dataWithKey = FreebaseDataWithKey.GetDataContext()
let travelDestinations = dataWithKey.Commons.Travel.``Travel destinations``
let all = travelDestinations |> Seq.toList
let first = all.Head.Name
As you can see, I have access to Travel Destinations, so the provider shows me data correctly but when I execute it:
Script.fsx(17,38): error FS0039: The field, constructor or member 'Commons' is not defined
The weird thing is that if I delete the google key, and use the provider, this error does not happen. Any clues?
In a provider like freebase, we need to do things asynchronously, and that unfortunately causes the error reporting not to be very good (see https://github.com/fsharp/fsharp/issues/280)
What's probably happening is that freebase is returning errors due to the api key not being right or something similar, and does errors are not surfacing, as the toplevel objects are already cached. You can either look under Fiddler to see the json being returned, use data.DataContext.SendingQuery or data.DataContext.SendingRequest, or clean the cache by deleting the FreebaseSchema and FreebaseRuntime folders under your temporary internet files system folder.
We recently tried to change this to cause errors to surface by generating the toplevel types synchronously, but that caused other problems (https://github.com/fsharp/FSharp.Data/issues/522)
I am following the MSDN tutorial for the WsdlService type provider found here. When I run it at home, it works as expected. When I write the same code at work, I am getting a design time exception:
The type provider
'Microsoft.FSharp.Data.TypeProviders.DesignTime.DataProviders'
reported an error: Error: Cannot obtain Metadata from
http://msrmaps.com/TerraService2.asmx?WSDL
Work does use a proxy and I have to alter the web.config to use a default proxy when consuming WSDL from a C# project in VS2012. When I looked at the parameters for the type provider, I don't see a mention about a proxy. Does anyone have any suggestions?
Thanks in advance.
Expanding on Tomas's answer...
This is a common pattern in the built-in type providers today:
At design time, if you need any kind of non-default configuration (e.g. credentials, proxy config, ...), the type provider will not work. You need to download some schema file locally (e.g. DB schema file, ODATA $metadata file, WSDL schema file...), and point the type provider at that, usually by passing LocalSchemaFile="...", ForceUpdate=false in the static constructor. This feeds the TP all the info it needs to generate the types.
Then, you set all of your non-default config programmatically on the objects that are created for you, so that everything works at runtime.
Here's another example of essentially the same issue, where this pattern is used to set credentials.
In the case of WSDL, below is the programmatic approach to set the proxy after-the-fact (i.e. step #2). Cribbed entirely from this answer, which is exactly what you want, in C#. You'll probably need to play with this a bit to make it work for you.
#r "System.ServiceModel.dll"
#r "FSharp.Data.TypeProviders.dll"
open Microsoft.FSharp.Data.TypeProviders
type Terra = WsdlService< ServiceUri="N/A", ForceUpdate = false,
LocalSchemaFile = #"C:\temp\terra.wsdlschema">
let terra = Terra.GetTerraServiceSoap()
let binding = terra.DataContext.Endpoint.Binding :?> System.ServiceModel.BasicHttpBinding
binding.ProxyAddress <- System.Uri("http://127.0.0.1:8888")
binding.BypassProxyOnLocal <- false
binding.UseDefaultWebProxy <- false
terra.GetPlaceList("New York", 1, false)
I'm not connecting through a proxy, so I have no way of actually testing this, but I think you should be able to use local WSDL file to load the type provider in the designer.
Try downloading the WSDL schema (from http://msrmaps.com/TerraService2.asmx?WSDL) and saving that to a local file (such as C:\temp\terra.wsdlschema). Then you should be able to write:
#r "System.ServiceModel.dll"
#r "FSharp.Data.TypeProviders.dll"
open Microsoft.FSharp.Data.TypeProviders
type Terra = WsdlService< ServiceUri="N/A", ForceUpdate = false,
LocalSchemaFile = #"C:\temp\terra.wsdlschema">
let terra = Terra.GetTerraServiceSoap()
terra.GetPlaceList("New York", 1, false)
The ServiceUri parameter seems to be required, but it should be ignored if you add ForceUpdate=false. It should only require the cached WSDL file. I'm not entirely sure how to configure the runtime to use your config file setting, but I'm sure this can be done in some way (either it just works or you can pass something to the GetTerraServiceSoap method).
Sadly, the type provider does not statically know (at design time) where to look for the config file, so it ignores it.
One of my users at a large university (with, I imagine, the aggressive security settings that university IT departments general have on their computers) is getting an empty string returned by Windows XP for CSIDL_COMMON_APPDATA or CSIDL_PERSONAL. (I'm not sure which of these is returning the empty string, because I haven't yet examined his computer to see how he's installed the software, but I'm pretty sure it's the COMMON_APPDATA...)
Has anyone encountered this or have suggestions on how to deal with this?
Here's the Delphi code I'm using to retrieve the value:
Function GetSpecialFolder( FolderID: Integer):String;
var
PIDL: PItemIDList;
Path: array[0..MAX_PATH] of Char;
begin
SHGetSpecialFolderLocation(Application.Handle, FolderID, PIDL);
SHGetPathFromIDList(PIDL, Path);
Result := Path;
end; { GetSpecialFolder }
ShowMessage(GetSpecialFolder(CSIDL_COMMON_APPDATA)); <--- This is an empty string
Edit:
Figuring out this API made me feel like I was chasing my tail - I went in circles trying to find the right call. This method and others similar to it are said to be deprecated by Microsoft (as well as by a earlier poster to this question (#TLama?) who subsequently deleted the post.) But, it seems like most of us, including me, regularly and safely ignore that status.
In my searches, I found a good answer here on SO from some time ago, including sample code for the non-deprecated way of doing this: what causes this error 'Unable to write to application file.ini'.
If you want to find out why an API call is failing you need to check the return values. That's what is missing in this code.
You need to treat each function on its own merits. Read the documentation on MSDN. In the case of SHGetSpecialFolderLocation, the return value is an HRESULT. For SHGetPathFromIDList you get back a BOOL. If that is FALSE then the call failed.
The likely culprit here is SHGetSpecialFolderLocation, the code that receives the CSIDL, but you must check for errors whenever you call Windows API functions.
Taking a look at the documentation for CSIDL we see this:
CSIDL_COMMON_APPDATA
Version 5.0. The file system directory that contains application data for all users. A typical path is C:\Documents and Settings\All
Users\Application Data. This folder is used for application data that
is not user specific. For example, an application can store a
spell-check dictionary, a database of clip art, or a log file in the
CSIDL_COMMON_APPDATA folder. This information will not roam and is
available to anyone using the computer.
If the machine has a shell version lower than 5.0, then this CSIDL value is not supported. That's the only documented failure mode for this CSIDL value. I don't think that applies to your situation, so you'll just have to see what the HRESULT status code has to say.