I am working on a desktop application using VB.net which stores data on an sqlite database. The client says that they want the app to be accessed over the LAN by different departments. Is it possible that SQLIte can work in this setup?
No. SQLite isn't meant to be used by multiple clients at the same time (unless it is strictly read-only).
You should use a server style database (SQL Server, PostgreSQL, MySQL, etc.).
If you really want a file-based database, Access is the only one I know of that will work over a LAN with multiple users.
Yes. SQLite can access database files on a network file system, and does handle concurrent accesses correctly (if the OS and the network implement locking correctly (many don't; see How To Corrupt An SQLite Database File)).
However, SQLite is a file-based database system; like Access, it is not really designed for network operation (see Appropriate Uses For SQLite).
Consider using a client/server database, if possible.
Related
What is the difference between single user database and multiple user database? Why I would need to use a single user database? why it was made?
If I have multiple threads accessing the same database on the same time using the same log-in credentials, do I need a multiple user database?
What is the difference between single user database and multiple user
database? Why I would need to use a single user database? why it was
made?
Single-user mode allows only one connection to a database at a given moment in time.
Since you've tagged this question as SQLite I'll base my answer on that specific engine.
SQLite's concurrency protection model is based on direct file reads and writes to the database file on disk, so obviously two different programs can't be writing to the same file on a disk at the exact same time. SQLite will force the second query to wait while changes are being made to the database file.
SQLite protects against file/database corruption using operating system file locks when INSERTS and UPDATES are being done. But it does allow multiple read-only handles at the same time (just like how you can open same the file multiple times in read-only on your desktop, but won't be able to save changes).
In other databases like SQL Server, single-user mode is often only used when the database needs maintenance - like restoring a backup file, changing the database structure, or changing global database settings.
Single-user mode is useful because you can't have clients connected and trying to read/write data while you are making these kinds of changes.
But under normal conditions, you don't want to run SQL Server in single-user mode for performance reasons. However, unless you have a high-volume webservice, SQLite will probably be able to handle the performance requirements despite changes being one at a time on disk.
If I have multiple threads accessing the same database on the same time using the same log-in credentials, do I need a multiple user database?
No, it will still work. And SQLite databases don't require authentication at all, there are no credentials for it other than file/directory permissions.
According to my system i have maintained two databases in LAN and online db.But i want to synchronize these two databases. I hope to do this things using microsoft sync frame work.
.http://msdn.microsoft.com/en-us/library/ee819079.aspx
Can i do sync local and online sql db using this? or any suitable method for do this.thank you
Sync Framework is designed for occasionally connected systems, eg. a laptop that can access the corporate network every other day and update its database, but needs to work when it has no corpnet access too. The pairing of Sync Framework is usually a central DB (SQL Server) and local embedded SQL Server Compact or SQL Express on the devices (laptops, phones, tablets etc).
IF the databases are always connected (eg. two DBs in two servers, with 24x7 connectivity between them, even if over Internet) then the appropriate technology is replication. Either Merge or Transactional. Theoretically replication also works when disconnect periods are expected, but Sync Framework is much better at it, and most importantly Sync Framework is not strongly dependent on DNS names as replication is (very important for occasionally connected systems).
Synchronizing the database is a vague term, you have to consider if you want a Master-Slave replication shcme or a Master-Master (the later being very difficult to achieve) and you have to consider what do you want replicated from the database. You also need to consider if more partners will be later added (more databases to 'synchronize'). And you have to be way more careful now about schema changes.
I need to choose a database solution for multiple simultaneous users of windows based applications using the same database on a file server.
I need a database that can live on a Window OS file server.
Must be shared by several applications running on individual MS
Windows machines (mostly Windows 7)
Made available by file server.
Cannot use a database server/engine (due to internal political rules) or
webpage server.
Prefer using C# for a set of WPF applications.
Currently using set of VB applications with a set of MS Access
files - one of these applications has problems and needs a re-write.
Current set of about a half-dozen *.mdb files (some with link
tables) are about 400 MB. Growth at a guess of 10 to 20 MB/year.
Up to about a dozen concurrent users each on their own PC
currently. Don't expect much change on this in the future.
All apps both read and write data to the database.
Currently several (about 4 people) write ad hoc queries in Access -
they will continue to need to be able to write queries somehow.
Would like to prevent changes in database structure (adding
tables/columns) by end users.
Free software.
The choices I know about are:
Access .mdb files (the current situation).
SQLite.
SQL Server CE.
Are there other systems that might work that fit many or all of the desired characteristics? Are there particular "gotchas" I should know about for the systems that I am considering?
Well, "Cannot use a database server/engine" makes things harder. So does "free".
I think Access is the only thing in your list that comes close to fulfilling all the requirements. It's not free, but it seems you already have it, so at least it doesn't cost extra.
Access is essentially three different, bundled products.
Jet database engine
RAD environment for queries, forms, and reports
VBA programming environment
If you're using only the database engine, it makes sense to do some testing with SQL Server CE.
Switching to SQLite would probably require additional checks in application code. SQLite supports storage classes, not data types. What does that mean? It means SQLite allows this.
sqlite> create table foo (n integer);
sqlite> insert into foo values ('wibble');
sqlite> select n from foo;
wibble
HyperSQL is another possibility. Supports only JDBC, might run without a server component. (Docs weren't immediately clear about that.) I think it would require a lot more work to switch to this than to SQL Server CE.
See also H2 and Firebird.
My database must be updated at arbitrary intervals, manually, with new info to put on standart tables that don't require structural modifications. one app will update the database.
Another app, the one I will distribute (to friends and family only, but doesn't require any security feature to it, like encrypting the database) will read the database and use its data on labels, listviews, etc.
The problem is, I'm the perfect definition of full-fledged n00b at programming of any sort, and still don't know what database to use.
I thought that I should use a SQL CE (*.sdf) file, and store that database thing on an FTP. then, I could download it and get data from it everytime the "client" app runs, and certain button ("connect") is clicked.
After some hard-core googling, I found out how to connect to the sdf thing, using this connection string:
Provider=Microsoft.SQLSERVER.CE.OLEDB.3.5;Data Source=D:\Documents and Settings\Camilo\JCTM.sdf
So it connects, or at least didn't show any error.
I don't know if it's a good idea to use sdf SQL CE files as databases, if it's too hard maybe I should go for XML? what do you guys suggest, what is the easiest way to implement very simple databases in VB.NET?
By simple databases I mean:
- no search needed
- no advanced features except storing strings on tables with columns and rows
- easy to access, read, edit, etc. by different VB.NET apps
Is sdf a good idea?
I would recommend Sql Server Express Its free and can be redistributed with .net applications as part of the install process.
The challenge will be syncing the changes between the different clients. If you have access to a FTP server, you may have the ability to host a website in IIS. If you can do that you can just use webservices and read against one database instead of copying one local.
Luckily for you, you can abstract away the need to be concerned with which back-end database you use to store your data.
Technologies such as ODBC (Open Database Connectivity) and OLEDB (Object Linking and Embedding, Database) allow you to limit your concern for the backend datastore to the task of crafting your connection string. In your example, the connection string says, "I'm going to connect to a SQL Server CE database via its OLEDB provider, and it's physically located over on D:/...
Within the code, you use standard OLEDB mechanisms to access and manage the database. Because of this abstraction, you can use OLEDB providers for SQL Server, Oracle, XML, Access or comma delimited text files as your backing store if you wish, and the only change you need to make to your code is the connection string. Your choice then should be to pick the database that you have the tools and know-how to set up and manage initially.
I'd start with Microsoft Access because it has its own UI, and can play well with .NET.
You can also try the ADO.Net implementation for SQLite, which I've also found very useful.
I've written a small (8-10 laptops) point-of-sale system running over a wireless network, as an HTA that reads from/writes to an Access MDB located on a network share.
I need to use ADO - GetString and the user roster are not available with DAO.
I also need to use DAO - the MDB cannot be compacted with ADO.
I know that:
1) If the database backend is not an Access MDB, I should use ADO.
2) If the backend is an MDB, but I want to upgrade to SQL Server at some point, I should use ADO.
3) Within an Access application, or any other VBA/VB application, I should use DAO, as ADO must go through a translation layer of the Jet OLE DB Provider, while DAO is more direct.
4) VBScript/JScript allows me to use either DAO or ADO.
The two-part question is as follows:
1) In this software environment (HTA/scripting), is it better to use ADO rather than DAO?
2) Does ADO offer any benefits because the HTA is reading/writing over a wireless network?
If the only reason you need DAO is to compact the database, you can use DAO for that, and use ADO for everything else. You are not limited to using only ADO or DAO.
The biggest benefit of using ADO is that it will be easier to move to SQL Server Express when the time comes. You should do that sooner rather than later, as SQL Server Express offers all of the benefits of MSAccess databases without the drawbacks. SQL Server Express is free, and it will easily handle the system size you are proposing.
Access databases corrupt easily in a multi-user environment, especially when a wireless network is involved. If you are worried about losing the benefits of working in MSAccess, you can still attach to SQL Server using linked tables, and work with your SQL Server Express database that way.
You can also use JRO to compact your MDB file. This will be included with any recent version of MDAC, installed by default on XP and later systems. No installation of Access is necessary.
To answer your specific questions:
1) I would opt for ADO just because it is more current, and the same API can be used in other kinds of scripting, like LDAP/ActiveDirectory access, reading file system folders, reading MAPI mail, and working with other types of semi-structured text files like fixed width text and CSV. It's not specifically better for the HTA programming environment, but its perhaps better for you to learn a more widely applicable API. I also thinks it's an easier API to work with, but I started with it and only later worked on some older DAO projects.
2) One possible benefit that ADO provides is that of disconnected recordsets, which may have an advantage or at least suggest some architectural alternatives in your wireless network setup. You open a recordset, then disconnect it, so you can still work with the data in memory, but not have to leave a database connection open. Then at a later time you can reconnect and update the database. Also, you can work in a fully disconnected style by managing tables as local XML or ADTG files.
You might shoehorn DAO into working from VBScript but that's an odd pairing. ADO makes the most sense in general.
Another advantage of ADO would be that it supports RDS over DCOM or HTTP. This can be used to overcome many of the limitations of Jet MDBs used via file sharing, such as the corruption unreliable networks and clients can lead to. It also cuts the amount of traffic over the network, improving performance. In addition it offers a middle tier in which business objects can "live" and all of this can be mediated using COM+ where applicable.
Of course you no longer have the option of using a simple P2P network and a file share to host the database. RDS needs a server to host the process and run the Jet engine, which no longer needs to run on each client system. This means you can use Jet stored procedures that run on the server, offloading more client processing and network traffic. While not as sophisticated as T-SQL or other alternatives, this ADO/Jet 4.0 OLE DB Provider exclusive technology offers tangible benefits that can't be had using DAO.
RDS can mask much of the process of using disconnected Recordsets, simplifying client code. It uses ADTG under the hood, which was developed and optimized for this very purpose.
However using RDS requires more infrastructure and expertise than a simple file share. You might as well look into a low-end version of SQL Server.
In general I'd recommend using the jetcomp.exe utility to compact and repair, over either DAO or JRO. It offers a number of advantages.
If you can afford to use a HTA application with Access instead of a more performant platform, I would say you should go with the easiest api for you. The bottleneck will never be the abstraction of db access in your case. Still, DAO is really old.