I have problem with connecting to DBF files on remote location using OleDb.
When I use local path everything works fine.
My connection string:
string path_dbf = #"\\server\directory";
OleDbConnection conn = new OleDbConnection(#"Provider=VFPOLEDB.1;Data Source="+path_dbf+";");
I've tried to use OleDb and Odbc, but both have failed when I use remote location. I also try to use mapped directory under the OS, but it doesn't work.
I get error:
Error: Sys.Net.WebServiceFailedException: The server method 'MethodName' failed with the following error: System.Data.OleDb.OleDbException-- Invalid path or file name.
I also try to use Odbc DSN like this:
OdbcConnection conn = new OdbcConnection("dsn=MyDsnName;");
but it doesn't work. MyDsnName is Free Table directory type and it points to my mapped remote directory.
I don't have idea of any possible solution.
So I want to ask if there is a maybe some additional connection string options to do that or I do something wrong.
Thanks.
It is probably a permissions issue when running as a web app. The user which may be something like "USR_MACHINE" may not have proper permissions to the other server location and thus failing.
To confirm this, try changing your website service to "Run As" some other user that DOES have permissions, such as yourself... if STILL not a problem, then try running .net as the ADMINISTRATOR FOR CONFIRMATION PURPOSES ONLY, then revert back to the USR_MACHINE account.
Once you have confirmed, then you might want to create a somewhat restricted user so they only have access to the folder and features you want them to for security purposes.
Related
I'm writing some R code that queries a MongoDB database, imports records matching the query criteria into R, performs record linkage with another data source, and then pushes the updated records back into MongoDB.
The code needs to work with any instance of the MongoDB database. Some people have it installed as standalone on their own computers, while others have it installed on their organisational servers. Note that these are servers specific to individual organisations and not the public mongo server.
To test my code, I have access to both scenarios - one instance is set up on my own computer, and I have several remote server instances as well.
The MongoDB database has some APIs, but I was struggling with the adapting the APIs to include the correct syntax to form my query, so I thought I would try the mongolite package instead.
I was able to create a successful connection string for the MongoDB instance on my local computer, using my user ID (which I retrieve first with an API and save as the R object myids), password, the localhost and port number as below:
# Load library:
library(mongolite)
# Create connection:
con <- mongolite::mongo(collection = "person",
db = "go-data",
url = paste0("mongodb://localhost:3000",
myids$userid,
":",
rawToChar(password)))
I understood from reading the mongolite user manual that to create the connection string / URI, you skip the http or https part of the address and preface it with either mongodb:// when the Mongodb database is on a local computer, or mongodb+srv:// when the Mongodb database is on a remote server.
However, when I try just changing the prefix and login details for the remote server version, the connection fails. Say the URL for my remote server is https://mydb-r21.orgname.org/ which opens a web page where you can log in to the Mongodb database and interact with it via a graphical user interface. Just swapping localhost:3000 for the web address mydb-r21.orgname.org/ and supplying the relevant login credentials for that server doesn't work:
# Load library:
library(mongolite)
# Create connection:
con <- mongolite::mongo(collection = "person",
db = "go-data",
url = paste0("mongodb+srv://mydb-r21.orgname.org/",
myids$userid,
":",
rawToChar(password)))
When I try, this is the error I get:
Warning: [ERROR] Failed to look up SRV record "_mongodb._tcp.mydb-r21.orgname.org": DNS name does not exist.
Error: Invalid uri_string. Try mongodb://localhost
If I try changing to mongodb::// (not localhost because it isn't hosted locally) I get this:
Error: No suitable servers found (`serverSelectionTryOnce` set): [connection timeout calling hello on 'mydb-r21.orgname.org:27017']
Interestingly, the port that is suffixed in the error message is the correct one that I was expecting, but that still doesn't help me.
The documentation in the mongolite user manual and other places I've found online seem to add some read/write specifications to the connection string, but as I'm not very familiar with how connection strings are constructed, I don't know if these are specific to the databases they are using in their examples. I can't find any clear explanation of what the extra bits that are not part of the URL mean, e.g. as shown in this blog. All the prefixes seem to be a bit different too, so I am not even sure what would be appropriate to try in my case.
Can anyone explain why the connection string works fine with localhost:port number for the local instance, but doesn't work with the URL for the remote server / online instance?
Also what do I need to do to make the URI for the remote server valid?
I am using Team foundation server and I have a problem with the Database. What connection string should I use? I have my connection string on my computer but it's different for every computer.
You can solve this problem in a number of ways. I'm assuming here that your connection string is currently in a standard app.config or web.config file. Also, this list is almost certainly not exhaustive...
The simplest (but ugliest) is for each user to check out the config file and put their own connection string in locally. This works, but you will get unnecessary changes checked in to the config file.
If your developers are all using local instances of SQL and the database name is the same on each machine, you can simply use localhost or 127.0.0.1 in your connection string to point at the local machine. This will work on all machines as long as the database name is consistent.
You can move the connection string out of the config file, into a separate file or location that is not checked into TFS. For example, you could check for a userOverrides.config file (that you never check in), or pull the connection string from the registry instead. You could still use the core configuration file to provide a default value, but nobody would need to edit it for day-to-day work.
I have used the code below to open a SQLite database file that sits on a network computer for more than a year now almost on a daily basis. Suddenly this morning, I am not able to open the file programmatically.
private Boolean Connect(String strPathFile)
{
// Initialize the connection object.
this.DbConnection = null;
try
{
// DATABASE: Create the connection string and set the settings.
String strConnection = #"Data Source=" + strPathFile + #";Version=3;";
// DATABASE: Connect to the database.
this.DbConnection = new SQLiteConnection(strConnection);
this.DbConnection.Open();
return true;
}
catch (Exception ex)
{
MessageBox.Show(ex.Message);
}
return false;
}
The file is a network resource in the form "\Server\ShareName\FileName.db" (less the double quotes).
Here is the interesting thing. SQLite Administrator has no issues opening up the network database file, none, and repeatedly. I can also open up the file locally. I copied the file to my local drive and simply changed the path inside Visual Studio 2012 (VS2012).
The server seemed fine. It had gone through a reboot at some point since the last time that I checked on it. I presume a Microsoft Update. File Explorer has no issues browsing the folder, and as I said SQLite Administrator can open the network file.
I checked once again on permissions and everyone has full control as well as the server's users have full control, both on the security permissions and on the share permissions. I checked the folder and file, and permissions are the same. I expected as much, because SQLite Administrator can open the file. The server does not have a firewall set up, Windows Firewall or otherwise. I rechecked that this morning as well. Again, SQLite Administrator would have complained about that.
I verified writing, by making a copy of the file on the network drive using File Explorer. That had no issues.
The sever is a Windows Server 2003. I am using Windows 7 Professional 64-bit.
I also tried to open up the database in read only mode, but that failed as well. I was expecting that behavior. SQLite Administrator still works nicely.
I tried various other connection strings including SQLiteConnectionStringBuilder() just to see what happens, and all roads lead to Rome, namely:
System.Data.SQLite.SQLiteException occurred
HResult=-2147467259
Message=unable to open database file
Source=System.Data.SQLite
ErrorCode=14
StackTrace:
at System.Data.SQLite.SQLite3.Open(String strFilename, SQLiteConnectionFlags connectionFlags, SQLiteOpenFlagsEnum openFlags, Int32 maxPoolSize, Boolean usePool)
at System.Data.SQLite.SQLiteConnection.Open()
at SQL.cSQL.Connect(String strPathFile) in C:\<Path to source file>:line 367
InnerException:
Thoughts?
in version > 1.0.82.0
Double the leading two backslashes in the file name
(e.g. "\\\\network\share\file.db").
Use a mapped drive letter.
Use the SQLiteConnection constructor that takes the parseViaFramework
boolean argument and pass 'true' for that argument.
See the SQL post here
Assuming the db file is accessible (e.g. "because SQLite Administrator can open the file"), then option #2 from the answer by ranmoro and GEEF seems to work. This becomes:
bool parseViaFramework = true;
con = new SQLiteConnection( cs, parseViaFramework );
in code. The rationale is discussed in the SQLite check-in comment "mistachkin added on 2013-05-25 21:06:45" in https://system.data.sqlite.org/index.html/info/bbdda6eae2
My connection strings are of the form:
URI=file:\\SERVER\Data\SqlData\History.db
for UNC paths, or
URI=file:C:\Data\SqlData\History.db
for local paths.
I am using:
Visual Studio 2022
<TargetFramework>net5.0-windows</TargetFramework>
<PackageReference Include="System.Data.SQLite.Core" Version="1.0.115.5" />
I had a similar issue. Replacing the UNC (\server\share\folder\file.db) with a mapped drive path (S:\folder\file.db) resolve the issue in my instance.
The error message is very misleading + irritating. Applications working fine in the local environment get failed to start in client server situation.
It has mostly noting to do with the code. Its related to server side.
Make sure the Write access is available for the server folder containing the file.
UNC [IP based server path] is not supported still, the network path/folder should be mapped to overcome this issue.
Some sites+users are saying to mention the Version No. in the connection string. All my applications are working fine without using it.
Connection String:
Data Source=[Mapped Server Location]\[SubFolders]\[FileName].db;
Update:
I tried to prepend \\ to the UNC path and it worked (added additional \\ in the beginning only, not in-between).
Data Source=\\[UNC]\[SubFolders]\[FileName].db;
I am connecting to a Teradata database through ODBC with Stata on an Ubuntu server (12.04 LTS). Everything works fine, except that I have my TD userid and password stored in the .odbc.ini file, which seems like a terrible idea. The alternative is to enter them in Stata, which seems even worse and is awkward. Is there a way to do this more securely? The login info that I use to ssh into the server is synced with the TD database. It seems that it should be possible to pass that information along.
In ODBC terms you do not need to store usernames / passwords in any of your ODBC ini files. Both the ODBC SQLConnect and SQLDriverConnect support the passing in of username / password at the time they are called.
SQLDriverConnect would need something in your InConnectionString like "DSN=YourDataSourceName;UID=username;PWD=password".
You could go one step further and pass in the whole DSN as a command line argument thus meaning that you would not need an ODBC data source in an ini file. I'm sure one of the forum readers can post a sample for you from Teradata.
As for passing in the user name and password from your SSH loging. Your application would need to capture that and pass it to ODBC.
If you want to establish a finer grain of security around your odbc.ini file or other files on your Ubuntu server that may contain user credentials I would strongly suggest the use of Access Control Lists (ACLs). Beyond the typical Owner::Group::World permissions you can specify permissions down to the specific user on whether they are allowed or denied an explicit permission for a given file.
Other options regarding security on Teradata include the use of LDAP authentication if your environment supports it. Configuring LDAP on Teradata is beyond the scope of SO and in many cases a billable, professional services engagement with Teradata's Information Security CoE.
I have a simple access database that resides on a network drive. All of the people that need to make any modifications to this database have access on their machine, but they would like to have a read-only website just displaying the data contained in it. I set up a website and tried using the accessdatasource, and while I could connect, it had issues whenever a user had the database open in access. I swapped to using a sqldatasource with a connection string set up according to www.connectionstrings.com, but I seem to be having either the same or similar issues, depending on how I set up the string/database. Basically, the entire issue is, if the database is opened by any user, the webpage is prevented from opening the database. Is it possible to open the database read only from the webpage?
It is an access 2000 database, but everyone is using copies of access 2007, and in all of these instances, the ASP.NET user has read/write access to the network directory containing the database, and read access to the database itself.
When I use the connection string:
ConnectionString="Provider=Microsoft.Jet.OLEDB.4.0;Data Source=\\<source>\<database>.mdb;User Id=<USER>;Password=<PASSWORD>;Mode=Share Deny Write;"
Where is not the default "admin" user, and is configured to have open/run (not open/exclusive) permissions on the database, I get the error:
Cannot start your application. The workgroup information file is missing or opened exclusively by another user.
As far as I can tell, there is no workgroup information file, but I am not really sure what I am doing there.
When is the default "admin" user, I get the error:
Could not use ''; file already in use.
If someone has the database currently open, otherwise, it works fine.
And finally, if I use the connection string:
ConnectionString="Provider=Microsoft.Jet.OLEDB.4.0;Data Source=\\<source>\<database>.mdb;User Id=<USER>;Password=<PASSWORD>;Mode=Read;"
I get the error:
Could not lock file.
I have been googling this for the past several days now and I feel like I've just been going around in circles. Any insight at all would be appreciated.
As it's Access 2000 format there will definately have to be a workgroup file (.mdw) even if that has no security set as such. I would try the connection string whereby you also specify the workgroup location e.g:
Provider=Microsoft.Jet.OLEDB.4.0;Data Source=C:\mydatabase.mdb;Jet OLEDB:System Database=system.mdw;User ID=myUsername;Password=myPassword;
Furthermore, I wouldn't recommend setting the read/write properties in the connection string, instead I think you would be better to create an account in the workgroup file and only assign it read only priviledges.
Update:
This is the ODBC connection method:
Driver={Microsoft Access Driver (*.mdb)};Dbq=C:\mydatabase.mdb;Uid=Admin;Pwd=;