I have many LinqPad scripts I use to query databases. These files are all in dropbox so I have all my queries available across computers. Very handy.
However each script is tied to a database connection, and that connection is not valid across computers. I'm guessing it has to do with how the passwords are stored. And that's OK.
But what is annoying is when I open a script, LinqPad attempts to connect to the invalid database. It is frozen while this happens. Once it is done, all I have to do is change it to the new db and it's fine. But this freeze interrupts my flow.
Is there a way to tell Linqpad to NOT try to connect when I open a file?
you can use a connection by connection string
so you can add some read key or any machanics to execute connection
using(TypedDataContext context = new TypedDataContext(Connection.ConnectionString)){
context.table.Where(w=>w.ID == 123);
}
Related
I have many LinqPad scripts I use to query databases. These files are all in dropbox so I have all my queries available across computers. Very handy.
However each script is tied to a database connection, and that connection does not work on different computers. I'm guessing it has to do with how the passwords are stored. Is there a way to get the db connections in the linqpad scripts to be valid across different computers?
After opening the query on another computer, right-click the connection that automatically appears in the Schema Explorer, update the password, and click 'Remember this connection'.
This saves the connection details to your local computer, which takes precedence over the connection details stored in your query.
I created an Access front end for a SQL DB on my PC for use throughout my company. I am using a file ODBC connection and putting both the ODBC file and the Access file on a shared network drive.
When I load the access file, for some reason it seems to default to using my windows login credentials and pulls in the data perfectly. When a user attempts to open the file, they receive an error message saying "ODBC --call failed.". I can open the Linked Table Manager for them and check 'ask for new location' then specify the ODBC file and it all works fine...however it doesn't seem to save anything. I get the error each time someone other then myself opens this file.
Any idea what could be wrong? I am not an Access guy by trade, it just seems to be the tool we need for the moment.
--EDIT: For Clarification I am using a file ODBC connection
--Edit 2--
Riddle me this. So I have been troubleshooting this issue and I came across something interesting. I was logged in as one of my users and did the following:
Create a new access file that references a file ODBC connection on the desktop.
Create 3-4 linked tables in the access file, using the ODBC file on the desktop.
Save and close the access file.
Re-Open said file.... and I get an ODBC connection error! Right after everything was fine in a fresh file!
Anyone ever experience this?
i assume you didn't install the ODBC correctly on each users PC.
you should create the ODBC-definition. You can create the relevant statements directly in the registry, see this branch
HKEY_LOCAL_MACHINE\SOFTWARE\ODBC\ODBC.INI
if you give the same name as on your developer machine, then it works. that's how i do it with my client applications that i develop on my machine and then install it at client site
After beating my head against the wall having this same issue, I finally discovered I had a checkbox on the Access form that defaulted to NULL. Since I put the backend into SQL, the checkbox fields cannot be NULL but the 'ODBC Call Failed' message did not help. I finally tried to add a record directly on the table via Access and it gave more information. I set all the checkboxes to default to zero and it resolved the problem!
Well, I was able to narrow the issue a bit. Access for some reason keeps trying to use Windows Credentials instead of the username in my ODBC file. I can't find a way around it, but I was able to resolve the issue by creating logins on my SQL Server for the windows users that need access.
I am not incredibly happy about needing to manage more logins, but that's what i did to resolve this issue.
I don't mean to resurrect the dead, but I had this same error stem from a different issue.
I was using an ODBC connection. When running the file using the 'Design' run button it worked fine. When I tried using the Navigation Pane and double clicking on it, the error would happen.
The structure of my query was the problem; I was porting a SQL server query over and the single quote ' parameter passing was not well received in Access. Changing these over to double quotes " made it work.
I've been struggling very hard to make this work. I'm using a software that uses paradox database, which I never used.
My problem is: I can open the program in multiple machines on the same time, but i can't seem to connect via ODBC when there is a program open in any machine (a .lck file maybe?). When noone is using the program I can connect without problems...
I understand that the lock file is there to protect the database integrity, but i wish just to make select commands via SQL directly into it... Is there any way to do it? A read-only connection maybe?
Thanks for the help!!
I had the same problem and I am living with this work around solution on the implementations of software I do where I work.
To make it work:
On the server machine of the paradox database, you have to create a new partition with the same letter where you will map on the client machines;
Share the unit drive;
On the client machines, map a new drive to the shared drive (repeating: the letter must be the same than in the server machine);
Put the database files in this drive;
Create the ODBC paradox system data source (it must be the 32 bit wizard) using the new directory for both Folder and Network folder;
Delete the existing .NET and .LCK before testing;
test...
I've read something about setting AUTO ODBC to TRUE on BDE too...
I'm new to ODBC and DSN's in general.
We have a product A that accesses a database "T" via a DSN D1 that has already been defined.
I'm now writing a test app testA that exercises various functionalities of product A and also needs to validate various database entries made by A.
For this, I am trying to access the same DSN D1 (that was setup for database T) to read from db and do the necessary validations.
I'm however having issues with that. I've setup the dsn, but when I do a SQLConnect with this dsn, I get a return value of -1.(I dont see any corresponding values for this return type either)n
Any clues on what this means and if I'm doing something wrong.Can we have 2 different processes or apps connect to the same DSN?
You can test access using a "udl" file. These files are largly misunderstood IMHO. They are simply a script that is used to launch the (db) connection library. You can create them by creating an empty file in notepad and changing the extension to .udl from .txt. You then double click on the file and configuer access to your database. (they launch a build in configeration applet). In my experience if a .udl file connects then any application will connect or 100% there is a problem with the application. If the udl file will not connect, then 100% there is a firewall or something probibiting access to the account being used to try to connect.
My application (a testcase automation tool) does not support calling ODBC's SQLSetStatmentOption. I need to set the cursor option SQL_SOPT_SS_CURSOR_OPTIONS to SQL_CO_FFO_AF. Right now I connect to the server using a connection string (no DSN). I am using sqlsrv32.dll or Sqlncl10.dll.
Is there a way to set the cursor option in a DSN (or other layer) between my tool and the MSSQL server? The tool handles creating the cursor (or results set) and iterating through the result set in a way that seems to obscure any ability to manage it directly. It does allow for calling SQLSetConnectAttr() but as far as I can tell there's no way to set a cursor option in there.
All of this is an attempt to speed up retrieving data over a remote connection. In SQL Management Studio I get comparable response times to the local or remote DB, but in the automation tool the remote queries take hundreds of times longer, probably because it seems to be making a round trip to the sever for every row.
There is no way to set statement options in the connection string that I know of. In ODBC 1.0 and 2.0 you could make calls to SQLSetConnectOption for statement attributes and they set those attributes in each statement created in that connection but a) that is an old version of the API (although it probably still works) b) you still cannot do it from the DSN. In unixODBC you can set some environment and connection attributes in the DSN but your obviously Windows.
I'm not convinced anyway that you've identified the problem correctly and even if you have, how do you know your app does not use SQLGetData (which is disabled when you set SQL_CO_FFO_AF). Are you sure you've not enabled MARs. Did you try getting an ODBC trace to see what the app is doing?