I have a SQLite database file in my PC. I have an offline application on my Windows CE. This app gets data from this file and updates them. The process is here:
1- initialize SQLite db file (in PC)
2- Copy db file to windows CE storage (in PC)
3- Some process on data (in Windows CE)
4- Copy db file to PC (in order to access the data) (in PC)
5- Do main app processes (in PC)
After a while the db records become large. I used indices and vacuum command on db and the problem solved.
Again after a while the db records become huge. Now copying the file takes long time. I want to remove steps 2 and 4 in order to speed up Get/Send events in PC app.
Connection string is my problem. Here is my code:
private string ConnectionString_SQLite = "";
public SQLite_()
{
string Data_Source_SQLite = `#"\\\Asset\System.db"`;
ConnectionString_SQLite = "Data Source=" + Data_Source_SQLite + ";Version=3;";
}
I tested these data sources in connection string:
#"\Asset\System.db"
#"\\Asset\System.db"
#"\\\Asset\System.db"
#"Computer\POINTMOBILE PM60\\\Asset\System.db" (copied from windows explorer address bar)
Is there anyway to access the file located in path \\Asset\?
Related
I have a database on the server shared on the local network. I would like to write an application that backs up the database from this server, but not on the server, but on the computer from which I started this application. That is, for a better understanding:
The database is on some Windows Server server. I have a laptop that is connected to the same network and has access to a database. On this laptop, I start the app, connect to the database and the .bak file is saved to the laptop, not the server.
At the moment I wrote only so much and unfortunately it doesn't work for me:
private static void CreateDatabaseBackup(string connectionString, string databaseName, string backupFilePath)
{
SqlConnection connection = new SqlConnection(connectionString);
SqlCommand backupCommand = connection.CreateCommand();
backupCommand.CommandText = $"BACKUP DATABASE {databaseName} TO DISK = '{backupFilePath}'";
connection.Open();
backupCommand.ExecuteNonQuery();
connection.Close();
}
This throws me an exception:
System.Data.SqlClient.SqlException: „Cannot open backup device 'C:\Backup\backup.bak'. Operating system error 3(The system cannot find the path specified.).
BACKUP DATABASE is terminating abnormally.”
Probably because of the fact that it is trying to save the file to the server's disk, and it does not have the path specified in the variable backupFilePath
I would like .bak to be saved to the disk of the device firing the application.
How to approach this problem?
My application does basic CRUD operations over an external .mdf file. The database file is created separately in SSMS. On my PC, everything works perfectly fine. When I install it on someone else's computer, it refuses to connect to the database. The other PC also has the same database at the exact same location.
The connection string I am using is (in app.config):
conString=Data Source =.\sqlexpress; Initial Catalog = dbName;
Integrated Security = True; Pooling = False
In my code:
dbConnection = new SqlConnection(Settings.Default.conString);
The other PC has SQL Server installed as well. Tried going through almost all the results but almost all of them suggest either
Adding the existing database with the project. I can't seem to do that because when I try that I get an error:
permission denied
I can't rewrite the whole code with a service based database pre-attached to it.
I'm developing an application that needs to access files on computers in an intranet, the files are database files and each computer has its own database, from what i have read i need to use a //server connection string, however I want to code my application in such a way that the user selects the computer they want to retrieve the that from for example they would select "Computer 2" and the application would create the connection string, connect to the database and populate it
I would recommend creating a connection string for each machine you are accessing in the web.config file and then using the user's selection to pull the correct connection string from the config file to instantiate the connection.
I have it working with this code
string myconnectionstring = #"Provider=Microsoft.Jet.OLEDB.4.0; Data Source=\\" + PCName + #"\data\data.mdb"
I've got this scenario: I developed a C# application which connect to a mdb file (Access 2003) through OleDBConnection (engine = Microsoft.Jet.OLEDB.4.0). This mdb file has some linked tables in another mdb file in the same directory. Everything works perfectly in the local environment, the query retrieves data from linked table even if I connect only the main mdb file. A simplified schema could be:
my application in the local machine --> C:\mydir\main.mdb --> C:\mydir\linked_tables.mdb
But this application should work in some host computers of a local network. And the mdb files are stored in a server in a shared directory. Well, when the application is running in a host I set the path as follow:
\\myserver\mydir\main.mdb
The connection works. The problem happens when I launch a query which tries to get data from linked tables. It tries to find the linked table in C:\mydir\linked_tables.mdb, but this path is on the server, not in the host.
Is there a way to tell him: if the path of the main mdb file is \\myserver\mydir\main.mdb you must (automatically) get the linked tables on \\myserver\mydir\linked_tables.mdb?
Thank you
I solved with another connection. I mean: for each mdb file I use a different OleDBConnection.
OleDbConnection MainConn = new OleDbConnection("\\myserver\mydir\main.mdb");
OleDbConnection LinkedTablesConn = new OleDbConnection("\\myserver\mydir\linked_tables.mdb");
Not so elegant, but it works. If I have to do some join of tables located in different databases, I manage them with some generic collection objects.
I am creating a application and I want to use a local database stored on the clients local machines. I am debating over if I should use SQLITE or is there something in Visual Studio to help me. The other thing is that I want to create the database programmatically in the users directory when the application is launched.
I am see a few things online but the articles were all about SQL Server stuff and that is not want I want to do with this application. All data will need to be stored on the local machine.
You can use SQL Server Compact, which has tooling in Visual Studio. It's syntax-compatible with SQL Server, but stores its data in a local file, which you can create on the fly (at app startup, for example).
You can create the SQLite database on the fly with the libraries provided from their website. I have used it in many projects for my personal code, as well as it being used in some of the internal architecture of Data Explorer (IBM Product). Some sample C# to create a database file:
if (!Directory.Exists(Application.StartupPath + "\\data"))
{
Directory.CreateDirectory(Application.StartupPath + "\\data");
}
SQLiteConnection conGlobal;
if (!File.Exists(dbGlobal))
{
conGlobal = new SQLiteConnection("Data Source=" + dbGlobal + ";New=True;Compress=True;PRAGMA synchronous = 1;PRAGMA journal_mode=WAL");
conGlobal.SetExtendedResultCodes(true);
firstRun = true;
}
else
{
conGlobal = new SQLiteConnection("Data Source=" + dbGlobal + ";Compress=True;PRAGMA synchronous = 1;PRAGMA journal_mode=WAL");
conGlobal.SetExtendedResultCodes(true);
}
try
{
conGlobal.Open();
}
catch (Exception)
{
//do stuff
}
Simply initiating a connection to the file will create it if the new=true is passed as the connection string. Then you can query it and get results just like you would any database.
You also have the ability to password protect the database files to prevent access to them from just opening them with an SQLite-Shell or a different SQLite DB viewer.
For more info on the pragma statements that are being passed in the connection string, see the following: http://www.sqlite.org/pragma.html
I'm not sure about programmatically (that's probably what you meant, right?) creating the database, but SQL Server Compact Edition has served me well in the past for simple apps. It's embedded and even runs in medium trust.