Best Database for Windows Server 2008 R2 with SQL 2005 - mysql

I'm writing the entire database system for a factory, this includes inventory, payroll, incoming and outgoing shipments, job-data, customers, etc. The database will be stored offsite on a server running Windows 2008 R2 with SQL 2005. The guy who runs the server sent me this too:
"We also have quickbooks installed on the server and we have Exchange 2010 running. The terminal server is also ws 2008 R2.
There is plenty of horsepower on the primary exchange/file server. Let me know if you have any other questions.".
I know my boss uses Quickbooks to look at reports and stuff like that. I'm not sure how relevant exchange 2010 is, nor what the significance of "terminal server is also ws 2008 r2" is. My boss wants me to write the entire system in ms access 2010, but I feel like this will be a lot more work than simply writing it in MySQL. Will my boss still be able to look at his reports in quickbooks if we change the database to MySQL? What would be a good database technology to use? I feel the most comfortable writing it in a scripting language using MySQL, but would still be happy if I could write it in something like C/C++. I've been trying to learn access, and it seems that setting up a front-end and back-end database in access would be a pain in the ass. There are going to be several sectors in the factory that will be using the client-side software to run queries and insertions into the database(I think around 5-6).
If I can write this thing in MySQL, I think I could do the whole thing fairly pain free, but I fear that I can't because it will be incompatible with Quickbooks and the previous database(Although I hear converting is fairly easy). Mostly just Quickbook compatibility is my problem.
How horrible would it be to write this thing in Ruby?
Thank you, any help is greatly appreciated.

I don't mean to be a spoil sport but there is a tremendous amount of naivety expressed in this question. It's hard to imagine that you will be successful in designing and implementing such a large system without a basic knowledge of the technologies involved.
A few thoughts:
Quickbooks already covers most of the features you say you will be responsible for implementing. Are you supplementing the existing Quickbooks system, replacing it, or what?
Quickbooks uses its own (extraordinarily slow) database engine. It isn't "compatible" with SQL Server, MySQL, or Access.
SQL Server 2005 is a database. You don't use a database with it, you use it as your database. A Microsoft-centric organization such as the one you describe is not likely to be interested in installing yet another database server like MySQL.
MS Access encompasses both a database "engine" (called JET) and a desktop development environment. The engine can be used with other development environments and the development environment can attach to other database engines (most often SQL Server, but others work too). When you say the boss wants to write the system in MS Access you need to be clear whether he means the engine, the development environment or both. (My guess is they want to use Access as the front-end development platform and SQL Server as the data store).
You will not write a system of this complexity in a month. You probably won't even design it in that time.

Quickbooks can use MySQL as a datasource (or just about anything else), but you'll need to make your database conform to the Quickbooks way of doing things: i.e., your tables will need to match the QB table structures. It sounds like you just need a front end (data entry forms and reports) and a custom back-end. Access can quickly turn into a nightmare if you don't put in some up-front design thought, but it does give you forms & reports & web pages free in a neat little package. Make sure you use an Access Data Project (adp) that's connected to a SQL Server back end. Access does have its own native database, but everything gets stored in one local file and it's not good for applications that will be accessed by multiple people in multiple locations. It also gets complicated when you need to make a change and roll it out to all of your users.
Another option is to look into a customizable web platform, like SalesForce or MS Dynamics. That will also let you create your own tables, forms, and reports, and updates are immediate for all users, but you'll have ongoing monthly user fees. They look great on a resume, though!

Related

SQL database questions [closed]

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 7 years ago.
Improve this question
So I have a couple questions that I would like to have cleared up for me. I have searched all over the internet for a month trying to find an answer to these questions. I really want to learn SQL and understand how the language interacts with its database. So here are a couple questions that I have had.
My understanding is that there is MySQL and other software applications that help you interact with your database. What are some other applications that could let me interact with my database?
If I am using MySQL where is the data being stored? On my computer or on a database somewhere else?
Where can I go to get a free SQL server and interact with it using an oracle application to interact with my database?
Can I store files and images in an SQL server?
So, lets say I have an SQL database and it has TONS of traffic running through it. What would I do to split the servers up, but still have then interact with each other? Would I create a database that tells where to send that data?
I know that Oracle, Microsoft, etc. have free SQL servers. Can somebody point me in the right direction? I am not exactly sure where to go to actually put my tables and such on a database. I do have the application however.
I have tons of other questions, but I will search as hard as I can for those. Thanks you for your response in the advance.
My understanding is that there is MySQL and other software applications that help you interact with your database. What are some other applications that could let me interact with my database?
MySQL , SQL Server , Oracle are softwares to be precise
Relational Database management systems RDBMS, they Manage (Store, retrieve ,
modify) data for you.
If I am using MySQL where is the data being stored? On my computer or on a database somewhere else?
Data will be stored in a database, database is really a file on your computer's
file system but you will not directly work with the actual physical
file, you will only work with the RDBMS and the RDBMS will manage that
file for you.
Where can I go to get a free SQL server and interact with it using an oracle application to interact with my database?
SQL Server Express is a free version.
Can I store files and images in an SQL server?
Yes in SQL Server you have the ability of storing files/documents using a feature
called FILESTREAM.
So, lets say I have an SQL database and it has TONS of traffic running through it. What would I do to split the servers up, but still have then interact with each other? Would I create a database that tells where to send that data?
For load balancing SQL Server has a feature called Replication
I know that Oracle, Microsoft, etc. have free SQL servers. Can somebody point me in the right direction? I am not exactly sure where to go to actually put my tables and such on a database.
Download link for Microsoft® SQL Server® 2012 Express
1) I think you might be getting the actual database software and the user interfaces confused for example MySQL is a piece of database software that manages the data stores retrieves it etc. phpMyAdmin is a GUI that you can use to interface with MySQL rather that writing SQL queries. There are other variants of SQL like SQL*Plus and i'm sure there are phpMyAdmin equivalents for all of them however I have only ever used them with the command line. Another alternative is something like MongoDB which is a noSQL database.
2) The data is stored wherever the database is installed. You could run it on a local server. LAMP (linux), WAMP(windows) or MAMP(mac) is the easiest way to get this set up. again look on youtube 100s of tutorials on this
3) http://www.oracle.com/technetwork/developer-tools/sql-developer/downloads/index.html I havent fully looked into this I must admit
I wont bother carrying on because M.Ali has posted a very good answers to the rest of the questions
Let's see if I can help you with this:
My understanding is that there is MySQL and other software applications that help you interact with your database. What are some other applications that could let me interact with my database?
MySQL, SQL-Server and others are Relational Database Management Systems (RDBMS for short); they are database software that help you store your data, following the relational model (columns are fields, rows are data-tuples, etcétera). RDBMSs handle the task of storing, updating and retrieving the data, but they are not, by themselves, "applications". An application (as I understand it) is a program designed to interact with a user, and sits between the user and the data stored in the database. So, this is a little schematic of what is going on
Database Application User
-------- ----------- ----
Stores data Receives user input/output Interacts with the app
and sends / updates / reads
data to/from the database
If I am using MySQL where is the data being stored? On my computer or on a database somewhere else?
It's stored in the computer where it's installed (in the simplest configuration). Each RDBMS may handle the data storage differently, but the bottom line is that the RDBMS "worries" about the data storage, and let's you handle the data with a "simple" and "consistent" language (most cases, using the particular SQL "dialect" of the RDBMS)
Where can I go to get a free SQL server and interact with it using an oracle application to interact with my database?
What do you mean by "Oracle application"? Oracle, as far as I know, is a RDBMS. If you want to get the free SQL-Server, go to the Microsoft Site and download it.
Can I store files and images in an SQL server?
Yes
So, lets say I have an SQL database and it has TONS of traffic running through it. What would I do to split the servers up, but still have then interact with each other? Would I create a database that tells where to send that data?
Many RDBMSs have tools to handle this (partitions, replication, etcetera). Read the documentation.
I know that Oracle, Microsoft, etc. have free SQL servers. Can somebody point me in the right direction? I am not exactly sure where to go to actually put my tables and such on a database. I do have the application however.
Google around. MySQL is free, PostgreSQL is free. SQL server has a free version. Also, Google around for a good SQL tutorial (I'd recommend you to learn how to use MySQL, because it's one of the easiest ones).
You should narrow your research. If you want a free, fully featured RDBMS, I'd recommend you use MySQL or PostgreSQL (I don't use SQL server, but that's just me). Also, if you want to develop applications, you should learn how to develop with other languages. Most (if not all) languages have libraries designed to interact with databases.
I would start here: http://www.w3schools.com/sql/sql_intro.asp. W3Schools does a decent job explaining the basics. From there you could branch out to http://www.tutorialspoint.com/sql/sql-rdbms-concepts.htm. A Google search from there would suffice to answer any other questions you may have.
MySQL, Oracle, and SQL Server are some that are used to create SQL databases.
MySql can be stored locally or on a host (godaddy).
MySql is free. I believe you have to pay to use the others.
Yes.
When you get to that point, you'll want to either hire someone, or work on databases and web traffic till you understand a good amount.
I would check with Godaddy, or some other web hosting site, and they can provide free advice.

Relational database management system, not for server but client-side

I am making a relational database for a friend who is not tech savvy. I am looking for something that she can upload the correctly formatted excel files into and be able to see the relationships clearly.
(<1>[John Smith]<2>[Sam Jones] rather than <1><6><2><244>, etc.)
I know I can make my own web-based system but I was not sure if there was an open source (or freely available) system already available, either desktop-based or web-based. I tried googling it but I am afraid that I am using the wrong keywords. (I only got server-side systems)
Any thoughts?
It's ugly and expensive, but MS/Access does this well. It's good for beginners and Excel integrates very well. If she has Office Professional she already has it. It also supports ODBC so it can use other database engines.
As far as desktop DBMS goes, as Peter Wooster pointed out (+1) MS Access is the most user friendly for people who are used to Office (e.g. especially Excel).
If you are thinking of building something with a web GUI (i.e. with ASP.NET) then you can get SQL Server Express for free and it can be deployed on a client PC.
There are other typically server-based RDBMS systems with workstation-friendly editions, such as MySQL and even Oracle (although there is nothing friendly about Oracle, workstation or otherwise).

SQL Server views not available via ODBC (reverse Engineer)

SQL Server 2008
Visio Pro 2003
Access 2003
System DSN used
I need to reverse engineer a SQL Server db, however the 'Views' box is "greyed out" when I attempt to do so (stored procedues are also "greyed out" but unecessary for my needs at this stage). I am using a SQL Server account that has sys_admin rights to connect via ODBC (ODBC needs to be used because Visio won't recognise the native connector, a well documented deficiency, and a trusted connection can't be used as I also have local admin rights and our company refuses to recognise local admins on cross machine connections). This is using the ODBC SQL Server type of connection. If I change the ODBC connection to use the native client type it allows me to select the stored procedures, unfortunately the views box is still not able to be selected.
I connected with Access using the plain SQL Server type of ODBC to see what I would be able to link and it allows me to see all tables, views, including system tables and views, which tells me the sys_admin rights are being preserved through the ODBC connection.
Am I missing something here? A number of searches on SO and Google have turned up nothing about why Visio can't see certain objects (disregarding security permissions as I have admin access), and being able to "see" them via Access has made me a bit more frustrated, as I would assume both products utilising an ODBC connection of the same type would encounter the same restrictions and functionality.
How do I get Visio to let me use the "Reverse Engineer" functionality to put the views from the SQL Server into my Visio document? I've done this before with other servers in the past.
I have created several new views in a SQL database and was unable to see them when attempting to link to them via Access. It always comes down to the fact that I have not given the user "Select" permission to either the SQL Database or the view. Be sure to check this. Just my 2 cents worth.
tl;dr
Don't use the OBDC driver, use the Access Visio driver.
Why?
As found here on SO:
An old thread but still a current problem ... I found that although
using the ODBC Generic Driver worked, the reverse engineering tool
then misses out Triggers, Check Clauses, Views and Stored Procedures.
By specifying the Access Visio Driver instead, at least we recover the
Check Clauses and Views.
In general, though, I have to say I think this shows an appalling lack
of regard for their customers on behalf of the relevant teams at
Microsoft. I had a very similar experience last year when upgrading to
Visual Studio 2010 only to discover that my SSIS projects no longer
opened ... as can be seen from this thread, MS could not care less.
There is really no reason to assume that a reverse engineering tool that's capable of documentation or diagraming the relationships between tables has anything to do with the fact that you have some saved queries? A view is only some saved SQL query and has NOTHING at all to do with relationships between tables.
A saved SQL query (aka a view) is NOT a table design structure. The creation of a view or the deletion of a view has NO BEARING WHATSOEVER IN ANY MATERIAL WAY in terms of the database structures and relationships you build in a database.
As a result the reason why with an conservative estimate of 1 trillion web pages in existence a Google or Bing search results in ABSOLUTELY NO RESULTS for your question.
In other words your assumption that a database ER diagram is to include a bunch of saved SQL queries is a complete and utter fallacy on your part.
Now you might be asking if such a documentation tool exists, but you actually asked WHY you cannot find any information on this subject and the simple answer is because nobody else on the planet and in fact as far as we know in the galaxy makes the assumption you're making.
being able to "see" them via Access has made me a bit more frustrated.
And it's not clear why you show even more confusion by asking why you can utilize such views in an application development tool such as MS Access?
The simple answer as to why you can see these views using Access is because Access is not a reverse engineering tool. In fact Access is also not a database documentation tool either.
Access is a software development tool that allows you to build applications and CONNECT TO A GIVEN DATABASE SYSTEM. Thus MS Access can use a database such as the native database engine that ships with the product (JET or now called ACE). Access can also connect to Oracle, or something like SQL server.
In ALL these cases without a doubt Access can connect to a SQL view since the tool is designed to CONSUME data from the particular database engine. However consuming data from a particular database system is a MASSIVE AND SPECTACULARLY DIFFERENT PROCESS then using a reverse engineering tool to ascertain the relationships between tables.
The fact that a database system has some relationships between tables, or you have enforced relationships that you wish to diagram has absolutely nothing to do with the process of having something document a bunch of simple SQL queries saved in some place. So all a view really is some saved SQL. You can save SQL in code, in text files, or in the case of Access in with what we called a select query, or in the case of SQL server you can save SQL as views.
However, looking at a bunch of saved SQL queries is an entirely different matter then documentation the existence of relationships between tables in a database. Creating views, delete views has ZERO bearing on those relationships between tables.
In fact we see that MS Access table diagram tool does not have the ability to include views in the table relationships diagraming tool included with the product. So in fact MOST development tools do NOT include views in the overall table ER diagram.
So at the end of the day the likely reason why something like Visio cannot simply consume and utilize a bunch is saved SQL queries is that by design such a tool is not intended for that purpose at all.

MS Access - Linked tables vs Access Data Project (ADP)? Security?

I am trying to determine the best approach when designing a new Access based application. Due to decisions made by others I have to use Access 2003 as my front end and SQL Server as my back-end data store (I would have preferred to use Winforms/WPF and SQL Server 2008 but that is another story).
Originally I was thinking of using Access Data Projects (ADP) as data security is a big issue in this project and ADPs would allow me to store everything (except VBA. reports, and forms) within SQL Server. Problem is that many developers I have spoken to suggest that using ADO is something that Microsoft has tried and then abandoned. They suggest using linked tables will provide a more consistent and less buggy experience.
I was hoping to get some feedback on what others think the best solution might be. Additionally, I would be interested to know if others consider linked tables to be a security risk over ADP. Thanks for any assistance.
Edit ... just wanted to add that the number of people using this application will be small (10 to 20). I should also add that this application is being developed from scratch. No conversion is needed.
ADPs have had no significant features added in a number of versions now. They also have some quirks compared to MDB/ACCDBs. There are probably less than 1% of the folks using ADPs who use MDBs/ACCDBs so support is much better for MDBs/ACCDBs.
The ADO part is immaterial as you can use either ADO or DAO.
If you use Windows authentication then there is no real difference between ADPs and linked tables as userid and passwords aren't stored in the linked tables metadata.
The number of users is immaterial. There is no reason why you couldn't have thousands of users in an Access FE against a SQL Server BE.

Issues using MS Access as a front-end to a MySQL database back-end?

Two users wanted to share the same database, originally written in MS Access, without conflicting with one another over a single MDB file.
I moved the tables from a simple MS Access database to MySQL using its Migration Toolkit (which works well, by the way) and set up Access to link to those tables via ODBC.
So far, I've run into the following:
You can't insert/update/delete rows in a table without a primary key (no surprise there).
AutoNumber fields in MS Access must be the primary key or they'll just end up as integer columns in MySQL (natch, why wouldn't it be the PK?)
The tables were migrated to MySQL's InnoDB table type, but the Access relationships didn't become MySQL foreign key constraints.
Once the database is in use, can I expect any other issues? Particularly when both users are working in the same table?
I know this topic is not too fresh, but just some additional explanations:
If you want to use MS Access effectively, especially with bigger, multiuser databases, please do the following:
split your MDB into frontend application and backend (data only) files - you'll have two separate MDB files then.
migrate all the tables with data and structure into external database. It can be: MySQL (works very well, no database size limitations, requires some more skills as it's not MS technology, but it is a good choice in many cases - moreover you can scale your backend with more RAM and additional CPUs, so everything depends on your needs and hardware capabilities); Oracle (if you have enough money or some kind of corporate license) or Oracle 10g XE (if this is not a problem, that the database size is limited up to 4 GB and it will always use 1 GB of RAM and 1 CPU), MS SQL Server 2008 (it's a great pair to have MS Access frontend and MS SQL Server backend in all the cases, but you have to pay for license! - advantages are: close integration, both technologies are form the same vendor; MS SQL Server is very easy to maintain an effective at the same time) or Express edition (same story like with Oracle XE - almost the same limitations).
relink your MS Access frontend with backend database. If you selected MS SQL Server for the backend then it will be as easy as to use the wizard from MS Access. For MySQL - you have to use ODBC drivers (it's simple and works very good). For Oracle - please do not use the ODBC drivers from Microsoft. These from Oracle will do their work much better (you can compare the time needed to execute SQL query from MS Access to Oracle via Oracle ODBC and MS Oracle ODBC drivers). At this point you'll have solid database backend and fully functional MS Access frontend - MDB file.
compile your MDB frontend to MDE - it will give you a lot of speed. Moreover, it's the only reasonable form of distributing MS Access application to your end users.
for daily work - use MDE file with MS Access frontend. For futher MS Access frontend development use MDB file.
don't use badly written ActiveX components to enhance MS Access frontend capabilities. Better write them yourself or buy the proper ones.
don't believe into the myths that there are a lot of issues with MS Access - this is a great product which can help in may occassions. The problem is a lot of people assume it's a toy or that MS Access is generaly simple. Usually they generate a lot of errors and issues by themselves and their lack of knowledge and experience. To be successfull with MS Access it is important to understand this tool - this is the same rule, like with any other technology outhere.
I can tell you that I'm using quite advanced MS Access fronted to MySQL backend and I'm very satisfied (as a developer which is maintaining this application). My friends, the users are also satisfied as they feel very comfortable with the GUI (frontend), the speed (MySQL), they don't have any issues with records locking or database performance.
Moreover, it's important to read a lot about good practices and other people experiences. I would say that in many cases MS Access is a good solution. I know a lot of dedicated, custom made systems which started as an experiment in form of private MS Access database (MDB file) and then evolved to: splitted MS Access (MDE - frontend, MDB - backend) and finally to: MS Access frontend (MDE) and "serious" database backend (mainly MS SQL Server and MySQL). It's also important that you can always use your MS Access solution as a working prototype - you have ready to use backend in your database (MySQL - let's assume) and you can rewrite frontend to the technology of your choice (web solution? maybe desktop C# application - what you require!).
I hope I helped some of you considering the work with MS Access.
Regards,
Wawrzyn
http://dcserwis.pl
I had an application that worked likewise: an MS Access frontend to a MySQL backend. It was such a huge pain that I ended up writing a Win32 frontend instead. From the top of my head, I encountered the following problems:
Development of the ODBC link seems to have ceased long ago. There are various different versions floating around --- very confusing. The ODBC link doesn't support Unicode/UTF8, and I remember there were other issues with it as well (though some could be overcome by careful configuration).
You probably want to manually tweak your db schema to make it compatible with MS Access. I see you already found out about the needed surrogate keys (i.e., int primary keys) :-)
You should keep in mind that you may need to use pass-through queries to do more sophisticated SQL manipulations of the MySQL database.
Be careful with using lots of VBA, as that tends to corrupt your frontend file. Regularly compressing the database (using main menu, Tools | Database utilities | Compress and restore, or something like that --- I'm using the Dutch version) and making lots of backups is necessary.
Access tends to cause lots of network traffic. Like, really huge lots. I haven't been able to find a solution for that. Using a network monitor is recommended if you want to keep an eye on that!
Access insists on storing booleans as 0/-1. IMHO, 0/+1 makes more sense, and I believe it is the default way of doing things in MySQL as well. Not a huge problem, but if your checkboxes don't work, you should definitely check this.
One possible alternative would be to put the backend (with the data) on a shared drive. I remember this is well-documented, also in the help. You may want to have a look at some general advice on splitting into a frontend and a backend and code that automatically reconnects to the backend on startup; I can also send you some more sample code, or post it here.
Otherwise, you might also want to consider MS SQL. I don't have experience with that, but I presume it works together with MS Access much more nicely!
Gareth Simpson opined:
If it's only two users, then Access
should do just fine if you put the
.mdb on a shared drive.
Er, no. There is no multi-user Access application for which each user should not have a dedicated copy of the front end. That means each user should have an MDB on their workstation. Why? Because the objects in front ends do not share well (not nearly as well as Jet data tables, though there aren't any of those in this scenario using MySQL as the back end).
Gareth Simpson continued:
I believe the recommended max
concurrent users for Access is 5 but
on occasion I've pushed it past this
and never come unstuck.
No, this is completely incorrect. The theoretical limit for users of an MDB is 255. That's not realistic, of course, as once you reach about 20 users you have to program your Access app carefully to work well (though the things you need to do in an Access-to-Jet app are the same kinds of things you'd do to make any server database application efficient, e.g., retrieving the smallest usable data sets).
In this case, since each user should have an individual copy of the front-end MDB, the multi-user limits of Access/Jet are simply not relevant at all.
I know this doesn't answer your question directly, but it might be worth checking out the SQL Server 2005 migration tool for Access. I've never used the tool, but it might be worth using with SQL Server 2005 Express Edition to see if there are the same issues as you had with MySQL
Dont forget to put some type time/date stamp on each record. sometimes ms access will think "another user has changed or deleted the record" and will not allow you to make a change! I found this out the hard way.
In general, it depends :)
I haven't had a lot of problems when the application side has just been updating the data through the forms. You can get warnings/errors when the same row has been updated by more than one user; but Access seems to be constantly updating its live record sets all the time.
Problems can happen if Alice is already working with record 365, and the Bob updates it, and then Alice tries to update it with her changes. As I recall, Alice will get a cryptic error message. It would be easier for the users if you trap these errors and at least give them a friendlier error message.
I've had more problems when I was editing records in the VB code through RecordSets, especially when combined with editing the same data on forms. That's not necessarily a multi user problem; however, you have almost the same situation because you have one user with multiple connections to the same data.
If it's only two users, then Access should do just fine if you put the .mdb on a shared drive.
Have you tried it first rather than just assume it will be a problem.
I believe the recommended max concurrent users for Access is 5 but on occasion I've pushed it past this and never come unstuck.
On the other hand I did once use Access as the front end to MySQL in a single user environment (me). It was a singularly unpleasant experience, I can't imagine it would become nicer with two users.