As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
Is it possible to make my MS access tables as a centralised location for storing data
I have an mdb access file to store data into a table using a form.
Is it possible to enter data to a centralised location?
this mdb file copies are used by five user at same time
Please help !
Jaison,
You CAN use Access as your centralized data store. SQL Server is the OPTIMAL choice if you are just starting off.
But it is simply NOT TRUE that access will choke in multi-user scenarios.
It IS true that you need a good backup strategy with the Access data file. But last I checked you need a good backup strategy with SQL Server, too. (With the very important caveat that SQL Server can do "hot" backups but not Access.)
So my answer is different...you CAN do this so that by the end of the day today you can be deployed and multi-user. Then perhaps you should begin moving toward upfitting your current application to use SQL Server.
I recently answered another question on how to split your database into two files. Here is the link.
Creating the Front End MDE
This should get you started.
Seth
Five is a very small number of users and Access works very well for small offices, if it is set up properly. The database must be split, with each user having a copy of the front-end. This does not mean that each user needs a full copy of Access, the runtime version is sufficient. 2007 runtime is free (http://www.microsoft.com/downloads/details.aspx?familyid=d9ae78d9-9dc6-4b38-9fa6-2c745a175aed&displaylang=en)
You should read this thread that deals with many misconceptions: Is MS Access (JET) suitable for multiuser access?
I ran a 10 user split front/back end application for several years without any real performance problems, though it obviously depends on the size of your data and I agree that the optimal solution would be to use a proper database server.
Crucially though, SQL Server Express requires installation on a server, whereas an Access .mdb back end can sit on a network drive. If you are in a low-resource environment where all you have is a network drive, then an Access set up is a good solution.
We did in the end migrate the data to SQL Server and redirected the front end, but more for security and backup purposes (centrally managed).
I'm with Galwegian on this one.
Install SQL Server Express or better. You will need to make sure that it allows remote connections see (http://blogs.msdn.com/sqlexpress/archive/2005/05/05/415084.aspx).
Then you can either:
Create a new Access Project that
uses the SQL Server database as it's
backend
or
Use Link tables in your current Access database to link to
the equivalent tables in SQL Server
Once this is up and running you can start to think about creating Queries/Stored Procedures on SQL Server instead of having this functionality in Access.
I have seen access choking many times in multi-user setups.
Don't do it - use something like SQL Server Express instead and save yourself a lot of hassle
If you've only got 5 users and your tables are pretty small, simply store the .mdb file on a file server and you should be fine. (Splitting the database into frontend and backend is probably not a bad idea.)
If you have a lot of users or a shared fileserver isn't an option, you might be able to use the EQL Data plugin to replicate the data up to a central server, without having to go so far as setting up MS SQL.
Access is not the best database for sharing data but it can be shared between several users. See here
You can divide your Access application into two files, one with the user interface (ui.mdb) and the other one with the actual tables (tab.mdb). The code in ui.mdb needs to reference the tables in tab.mdb.
That way, you can store your tab.mdb on a network share, where all users (each with a seperate ui.mdb on their local drive) can use it.
That being said, I fully agree with Galwegian: Don't do it.
One of the problems with your approach is,
the query is performed on the client. A select foo from bar where fizz = buzz query needs to load all fizz entries in bar to check if the where clause is true.
His approach replaces the tab.mdb with a small database server. That way you can send a query to the server, which returns only the requested data sets, with much less network activity.
Related
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
I have been doing quite a bit of research trying to figure out which database system would best suite my needs, but I need a little guidance. I am writing a VB.Net program that keeps track of inventory, to be used by small businesses. I will be using a client server type model, with 1 computer on the network acting as a server, the rest clients. The avg number of client computers will probably be 2-5 or so. The most would be 10-15. Right now I am using an Access DB stored on a network Hard drive, but that way is slower and not very stable. Access was the first DB for me to learn how to program with so that is why I am using it now, but I know I need to change that going forward.
Requirements:
I want the installation process to be easy and simple because these businesses will have no IT Dept. Database server needs to be installed along with program installation.
Items and customers will be continuously added, so database size limits concerns me a little bit, as I don't want to have problems later on when the database size gets maxed out.
Here is what I have gathered about the following DB types:
Access: What I use now. file based db. not intended for multiple users using 1 DB.
MySQL: Open source but seems distributing with program requires licensing, so this is out. I wish this was an option, but I need free.
SQL Server EXPRESS 2005/2008: No licensing, also 2008 R2 has a 10gb limit. I am leaning towards this for now. Seems to be easiest integration with VB.Net & Visual Studio. Prerequisites are available in Visual Studio (for SQL Server 2005) so SQL server will get installed during program installation.
SQL Server CE: file based db. maybe not the best choice for client/server setup? Might not be any better than how I use Access now. Correct me if I'm wrong.
Firebird: I see other programs are using it in a client/server type setup, but it looks like a file based db? Also looks like support for vb.net + firebird is scarce, which scares me. No limits though, which would be awesome.
I've done tons of research, but I still don't know which is best for my situation.
I think the approach you are taking is incorrect. You're asking your customers to install a RDBMS system and software when they don't have an IT department. Who is going to maintain this?
If this were me, I'd propose a hosted model web app perhaps using Windows Azure where you have a single centralized database for all your clients (create a multi-tenant database) and Microsoft handles all the infrastructure hassles. Or go with some third-part hosting solution that supports SQL Server 2012 (why consider 2005 or 2008?). Either would be better, IMO, than what you're proposing. And I believe it would be considerably easier to maintain and serve all your clients in this type of set up.
This is a repost of a question I asked 4 or 5 days ago, with zero response. Hoping for more luck this time...
(Using SQL Server 2008)
Within the next few weeks I plan to introduce SQL server to an office that is in dire need of a proper data server. Currently there is a heavy reliance on loose Excel and Access file (supplemented with frighteningly large amount of impenetrable VB code to do data manipulations) strewn all over the internal network.
We need SQL server for two things:
1. For internal databases that will be designed upfront and will be capturing data on an ongoing basis
2. For ad hoc uploads of datasets received from clients, which we then analyse
I am the only person in this office who is familiar with SQL. I will have to train the other 5 or 6 people to use it.
Now, my question is this: how would you guys set up the DBs so that it would be easy using Management Studio to visually recognize where what is being stored? To be more precise: if this were a windows file system it would look something like this:
c:\client work\client 1\piece of work 1 (db with 10 tables)\
c:\client work\client 1\piece of work 2 (db with 8 tables)\
c:\client work\client 1\piece of work 3 (db with 7 tables)\
c:\internal\accounting system\some db with 8 tables\
c:\internal\accounting system\some db with 5 tables\
c:\internal\some other system\some db with 7 tables\
etc.
So briefly, I need to visually split by internal and client work. Client work I need to split by different clients. For each client I need to split out the different distinct sets of work. (Internal work follows a similar pattern).
Solutions that I am aware of:
Run multiple data servers (e.g. one internal, one for client work). Not sure what the cons of this would be though
Assign schemas to tables
I would love to hear your suggestions!
Your organizational tools for managing SQL Server are instances, databases and schemas:
A server can run multiple instances. An instance is basically a completely separate server instance on the same machine.
An instance can manage multiple databases. The database is the standard boundary of integrity - you (usually) back up an entire database, referential integrity is constrained to being between objects in the same database, etc.
Each database can contain multiple schemas, which allow you to organize code.
All these "containers" relate to security in some way.
I recommend that you take an organization data and process inventory first, so that you understand what data you are dealing with, who uses it and how - with special attention on data which is public or collaborative (data used by certain people together) and which needs to be compartmentalized access (only used by a particular role). SQL Server is not really a great place of choice to be storing unstructured data - I would not view it as a simple replacement of a file server, for instance.
From there, proceed to define roles for your users. Having roles is a lot better strategy than assigning rights to individual users. It documents the semantic meaning of the access (any person performing this role needs this access as opposed to the user's identity - john and kate need access - this tells you nothing about why they need access). Be certain that the roles are sufficiently fine-grained. A departmental role like AccountsReceivable isn't nearly as useful as PaymentApprover or InvoiceProcessor or AccountsSupervisor. Users can act in multiple roles - this will give you a lot more self-documenting ability in your infrastructure and a lot fewer security holes and headaches.
This should help to define which containers you will need and what access to grant and guide your data infrastructure from there.
As far as giving users direct access, I'm with Randy Minder, SQL Server is only an expert user tool at best. If they are familiar with Access, a good option is to let them use Access against carefully designed and chosen views in SQL Server until they are ready for a more systematic data engineering approach.
IMO, users of your databases should not have to know or care where or how your databases are set up. And they shouldn't be given access to SSMS unless they are well trained in SQL. This is a disaster waiting to happen. You should be creating applications and/or reports that allow the user access to the data they need. That way they don't care where the data sits, and don't need to know.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
I was asked to provide an estimation to change a relatively small app designed with MS Access to use a SQL database.
First, is this even possible? I never worked enough with Access, so I'd like to know. If it's possible can you please point me to some websites with tutorials regarding this?
Second: if it's possible, is it recommended? Is it a big performance hit? Any specific do/donts that you can and want to share?
Thanks in advance for your help.
SQL Server upsizing is relatively easy to do although thorough testing is required. I'd estimate the effort at 5% to 10% of the initial system development. SQL Server upsizing is recommended in specific circumstances such as greater than 25 to 50 users or 24x7 access or difficulty/impossibility in rekeying data in the event of a corruption.
See my Random Thoughts on SQL Server Upsizing from Microsoft Access Tips page
There is a tool from the SQL Server group SQL Server Migration Assistant for Access (SSMA Access) which is a lot better than the upsizing wizard.
For the specific task of converting a Microsoft Access database to use SQL Server as the back-end data store while keeping the user interface from the Microsoft Access application, Access itself supplies an "Upsizing Wizard" (Tools | Database Utilities | Upsizing Wizard).
This wizard will step you through the process of connecting to an instance of SQL Server, creating an SQL Server database, and moving, to the greatest extent possible, your tables and views (called Queries in Access) to the new database.
The process can be relatively painless, or fraught with difficulty depending on numerous factors including how well you've validated your data in the Access database, whether you've made use of VBA functions in your queries, and whether you've used any query constructs unique to Access.
This tells you how to convert Access to SQL Server:
http://support.microsoft.com/kb/237980
Now, depending on how the application was written (language, etc.), the rest of it may be a quite a bit more work. However, it's really difficult to throw a ballpark on that one because the number of variables in this are large. In any case, it is possible, so that's not an issue.
In terms of performance, if the database is tiny, then Access may actually be faster. If the database is large, you'll gain from SQL server. Aside from that, you can have distributed clients and one data store centrally located, that's a plus.
By the way, if this is written using the .NET framework, it probably just got a lot easier.
This would be fairly easy to do (hopefully). In Access, you can create linked tables that are just links through to tables in other database (like SQL Server), so you could take your existing apps and replace all the Access tables with same-named links to tables in your SQL Server database.
I think doing this could be the opposite of a performance hit, depending on the circumstances. Access is very performant, but only with a small number of concurrent users (say, less than 30). So if the application has a large number of users, you would benefit from switching over to SQL Server. If, however, the SQL Server database is hosted on a different machine, than you lose performance by connecting to a database on a remote server (as opposed to connecting to a local Access database).
I wouldn't recommend doing this, personally.
to upsize or not to upsize - that is the question...(or was for us)
kind of a big deal to step up to sqlserver....we kind of dodged it by going to a WAN replication service from AccessTables.com and stayed with Access....at least for the time being.....the upsizing was just one issue...dealing with a web front end or terminal services was part of it too...
I really want to know, how to secure a firebird database from being opened by any user but from the application it self. If I distribute a desktop application with a single file Firebird database (not embedded), how to protect the database from being copied to another machine running Firebird with known sysdba password?
I have searched the question related with this subject, and only find this: Finding a legacy firebird/Interbase database password
If the answer in that post was true, how to use desktop application with firebird database and forbid any user to open it using another machine? Or should I use other database like mySQL or PostgreSQL?
PS: I use Delphi 2006 to develop the GUI.
You are missing the point when thinking about the password to the Firebird database - the server is open source, so there's no way to do what you want. The user can simply recompile the server with password checking commented out.
Basically there's only two things you could do:
Write your own modifications to the Firebird server, so that it writes a database file that is incompatible with all other servers. It doesn't matter then that people can transfer the database to another machine, as the standard server executables won't be able to access the data in the database.
Write only encrypted data to the file, so that it doesn't matter that access to the database is possible.
Both are of course not fool-proof either, as a determined cracker can simply use your own application to get at the data. Having permission to attach a debugger to the running process can be enough to halt execution of your application at any point in time and to examine the (decrypted) data in RAM. See also the SO question "How can I increase memory security in Delphi?", especially this answer, for more information on this topic.
BTW: this is something that can be done whatever database engine you choose, to answer the last part of your question.
how to use desktop application with firebird database and forbid any user to open it using another machine
If you mean that user has both the enrypted data and the key, you are doing DRM. The definitive answer is: you can't. You can slow down the user by hiding the key with different methods, but you can't stop them.
You don't.
This is more or less the same problem as Pidgin has in http://developer.pidgin.im/wiki/PlainTextPasswords, except that's protecting it from some users and not others, rather than your application and not any end users.
I'm currently developing an application that needs to store data in it's on database, I'm currently using SQL Server Express 2005 with Advanced Services (because we need full text search capabilities).
Local company lore says there have been all sorts of strange problems some years ago when two products used MS SQL Server with the default instance and they had interesting times cleaning everything up into making each application use a named instance.
As I can't remember the exact problems they had ... is it advisable for an application that has to run in a stable way without interference from some other application to have its database in its own named instance? If so, why? What additional isolation does that grant me as opposed to attaching the database to the default instance (or even use a watchacallit - user instance? - where you specify the mdb file location in the connection string).
Update:
The main concern I have is not performance/CPU - I'm talking about an application that manages Persons/Guests at the front desks of large organizations, think a hotel for example. I think even SQLite could easily handle the amount of data I need (disregarding some features like fulltext search).
My main concern is Customers installing stuff that interferes. From Mitchell's Answer and John's comment from it I think it is advisable to stay in a named instance - but if you have more reasons for that, please voice them.
A few things.
Using attached databases (User instance dbs) are a royal PITA for administrators to manage, as they must be attached to be accessible from SSMS and more.
Putting individual applications on their own named instances of SQL Server will create individual processes for each application, isolating resources and memory spaces for each.
Is it really necessary for each application to have its own instance of SQL Server? No, I would say typically it is not, unless it is truly 100% mission critical, however, if it is that critical, I would be surprised if it is running SQL Express.
I would recommend though from a maint. perspective that you use a standard database, rather than a user instance.