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.
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 11 years ago.
What advantage is there to using SQL Server Reporting Services instead of just using normal reporting through the application ?
I can understand that the data is on the SQL Server so perhaps this is a good place to serve the report from but what are the actual advantages in practice and is it worth converting your app to use Reporting Services?
As usual, it depends :-) If your application purpose is only to serve reports based on data from SQL Server 2005/2008 database, then using reporting services could give you this without a need to develop anything (maybe beside creating report definitions).
So what is given by reporting services:
reports designer (quite easy to use),
it could handle user authentication and authorization,
report subscriptions,
exporting reports to various formats (xls, csv, pdf).
This is only excerpt from full functionality of SSRS. I have used them only a little and quite a long time ago, so I could have forgotten something. As I remember MS prepared report viewer controls, which were usable in ASP.NET web sites and windows forms applications.
Additionally to what you have written in question- as far as I remember reporting services do not need to be installed on same server machine as SQL Server.
If reporting is only minor feature of your application and you have only few specified and already implemented reports, then maybe there is no need to use SSRS.
To summarize, in my opinion main advantages of Sql Server Reporting Services are:
they fullfill most reporting needs without need to develop all those
features,
they allow to create easily new reports,
they fit very well into MS environment and integrate easily with it.
Not all applications include reporting components, and those that do will normally have a limited set of reports available.
With SSRS - or any tool for writing your own reports (such as Crystal, Cognos, BIRT, Jasper etc.) - you can report any data from any data source you can access, in pretty much any format you require.
However, you will have to write the reports yourself.
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...
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.
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.
I was wondering if there are any alternatives to Microsoft's SQL Server Management Studio?
Not there's anything wrong with SSMS, but sometimes it just seem too big an application where all I want todo is browse/edit tables and run queries.
I've started using LinqPad. In addition to being more lightweight than SSMS, you can also practice writing LINQ queries- way more fun than boring old TSQL!
TOAD for MS SQL looks pretty good. I've never used it personally but I have used Quest's other products and they're solid.
Seems that no one mentioned Query Express (http://www.albahari.com/queryexpress.aspx) and a fork Query ExPlus (also link at the bottom of http://www.albahari.com/queryexpress.aspx)
BTW. First URL is the home page of Joseph Albahari who is the author of LINQPad (check out this killer tool)
Database .NET
I have been using Atlantis SQL Enywhere, a free software, for almost 6 months and has been working really well. Works with SQL 2005 and SQL 2008 versions. I am really impressed with its features and keyboard shortcuts are similar to VS, so makes the transition really smooth to a new editor.
Some of the features that are worth mentioning:
Intellisense that actually works when using multiple tables and joins with aliases
Suggestion of joins when using multiple tables (reduces time on typing, really neat)
Rich formatting of sql code, AutoIndent using Ctrl K, Ctrl D.
Better representation of SQL plans
Highlights variables declarations while they are used.
Table definition on mouse hover.
All these features have saved me lot of time.
powershell + sqlcmd :)
If you are already spending time in Visual Studio, then you can always use the Server Explorer to connect to any .Net compliant database server.
Provided you're using Professional or greater, you can create and edit tables and databases, run queries, etc.
There is an express version on SSMS that has considerably fewer features but still has the basics.
vim + dbext :)
Oracle has a free program called SQL Developer which will work with Microsoft SQL Server as well as Oracle & MySQL. When accessing SQL Server, however, Oracle SQL Developer is only intended to enable an easy migration to Oracle, so your SQL Server database is essentially read-only.
You can still install and use Query Analyzer from previous SQL Server versions.
How about Embarcadero Rapid SQL Really good but kind of expensive.
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.
I'm working on an open source project that uses SQL Server 2005 as the data store. We need a DB compare tool to generate diff scripts to be able to upgrade a DB from one version to another.
Is there an open source or free SQL Server DB diff tool out there that generates a convert script?
I think that Open DBiff does a good job.
It's simple and I works with SQL Server 2005/2008.
But only generate the change script. Nothing more and nothing less.
On CodePlex I noticed yesterday DbDiff (http://www.codeplex.com/OpenDBiff) that you could try. Supports Sql2005 and 2008, I did not try it.
I'd recommend spending some cash and getting Red Gate's SQL Compare tool which does an excellent job, and can even compare databases to Visual Studio database projects to generate upgrade scripts. It's fast and easy to use, and works well. The upgrade scripts are also of decent quality.
It's not that expensive. Probably less expensive than your time. Just think about how much your hourly rate is, and how many hours it might take to investigate an open-source tool and get it working (and how many you have already spent), then multiply them together. That's how much a 'free' tool is really costing you, which is often significantly more than a commercial tool.
It's not open source, but is free (as in beer): Sql Effects Accord (aka Clarity) Community Edition
AdeptSQL Diff and DataDiff are wonderful products, much cheaper than RedGate's and a much more simplified UI, and I have yet to run into a scenario it cannot handle.
Aloha
You might want to try SqlDbDiff. It can generate change scripts. The free edition does a good enough job.
Anyone try xSQL Bundle (xSQL Data Compare and xSQL Object Compare)? Our place only uses for DB diffs, no syncs, so can't say for syncing but the diff and reports are not bad.
Also, OpenDBDiff has a spin off, not sure which is better - http://code.google.com/p/sql-dbdiff/
Anyone know if any of the free/open source DB diff tools mentioned here offer scriptable / command line interface to automate the diffs and synching?
I looked into xSQL tools, they offer command line access but unfortunately, no scriptable command to export diff results to (report) file.
While it's not exactly what you want, I found this for postgres:
http://mbk.projects.postgresql.org/
It doesn't generate a diff to apply, but rather allows you to merge a full dump of the new version of the table with the previous version.
Hmm, none that I know of. You can always retrieve the definitions as SQL and then run a diff tool on them, but it's a bit of a pain in the rear.
Probably the best solution for this is using some kind of "Migrations" tool, so you can keep your database definitions together with your code, and version them, etc.
Update
On Sourceforge I found Whiz SQL Structure Compare with this description: Whiz is a database diff utility which will be useful to find difference between two MS-SQL Server databases. It also able to generate SQL script to update the changes from one database to another database.
However, I've been unsuccessful in getting it to work so far...
We have both SQL Delta and SQL Compare. Each has strengths, but each also have weaknesses that make them quite a pain.
SQL Delta will miss some triggers in its comparison, and it will take actions not found in the action list, and it will sometimes take actions you did not want it to take. That was discovered at quite a cost in time.
SQL Compare will catch the triggers, but they are embedded within the table listings. On a large database, that means going through each table and sifting them out. Something the tool should have isolated for us. Again, quite a cost in time.
Its is a little late, but I just relased a real simple project on code plex:
http://dbcompare.codeplex.com
Enter (or build) two connection strings and it will compare all Tables, Views and Stored Procedures.