I have an access database that connects to a vb6 application and this whole thing is connected between two computers via a shared network one running win 8 and other a win 7, and there is no internet involved in any sorta way nor should it be that is a requirement in fact
sorry I advance I have tried researching on the net but there is really short time and a lot of confusing material online
I am creating a WPF app connected to MySQL DB
now I have copied the access file and imported the contents of the DB in MySQL
things are a real mess in the imported DB so I am fixing it
what I am confused is how I am going to make it work there
do I go and install MySQL and do the whole process manually there, repeating all the steps and changes
is made
make a document that contains the code/script for all the changes I have made and run the data through
it, and is there even a way to implement that as a whole in a singular go
connect both databases together, i don't even know if this is possible
yes, in place of a simple "file share" of the Access file, you now are going to run some kind of SQL server system. In this case MySQL. But it could be PostgreSQL or any kind of "server" database.
That instance of "sql server" thus has to be setup, installed and you ensure that the "box" running that instance of MySQL also allows external connections (often by default the given computer firewall settings prevent this).
At that point, 2 or 10 different computers on that same network can now simply connect to the SQL server. The code of course is going to be VERY simular. You almost for sure used the oleDB provider for use with Access. However, you can use the ODBC provider, or even use the provider from MySQL. Those providers thus means you change the connect object, datareader object etc. However the "base" .net types such as row, or datatable, or dataset can remain as before (so you only change the provider). If you have a lot of code based on oleDB, then you could well consider to contine to use that oleDB provider code in .net, and thus you change the connection strings to now point to MySQL.
If you don't have a lot of code, then for sure do adopt the mySQL provider for .net. But as noted the least amount of changes would be to continue to use a oleDB provider for mysql, and that would suggest the least amount of code to be changed.
As for the msaccess data migration? Well, it not clear what tools and how you doing that now. But, once you transfer the data to the MySQL server (assuming you installed + setup my sql to run on one computer). The it is a simple matter to point your .net connection(s) in your code to Now MySQL as opposed to Acess. As a result, most if not all of your code logic for working with the tables can remain as before - but as noted you have to swap out the provider parts in .net
Now, if your REALLY lucky and the .net code used the ODBC provider? Then all you have to do is change your connection strings. And of course "some" SQL syntax in your code may have to be tweaked, as like Oracle, MS SQL server, postgreSQL, and MySQL?
Well, they all have some features and syntax that is different - this is especially in regards to date/time calculations, datediff() etc. But the general sql you have/had in your .net code should continue to run mostly un-changed against MySQL data tables.
As for how to migrate the data? I think that a really good tool is of course to use MS-Access. What you do is get MySQL up and running. Then use ms-access to open that database. You then add linked tables from MS-access to the MySQL tables.
At that point, you can now run append queries from Access to move/send the data to MySQL. It really depends on how many tables, and how many related tables are in that database. The more complex and the greater number of related tables in Access then the more the challenge to move such data up to MySQL.
Transferring Excel or a small or even big table is a breeze. (again, use MS Access and link to the tables on the sql server). However, where things can become messy is that if you have say 25 tables, and they are all related, many have cascade delete and say enforced parent to child relationships. So the more tables, and especially a larger number of related data tables, then the more work such a data migration task will become.
I think MS Access is a really good tool, since if you setup a connection to MySQL, then you can execute a transferDatabase commend in Access to send up one table to MySQL, and even all the columns and data types for those columns will be automatic created for you. So not only can Access transfer the data, but MORE valuable is it has the abilty to create the target tables on MySQL for you - and that will save you large amounts of time to build + setup the tables on MySQL.
Related
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.
I currently have a database in MySQL, which I'd like to import in MS Access.
Is it possible to do this while keeping all relationships intact (i.e. without exporting to .csv, or by using ODBC)?
I'm a noob in this area so any help is greatly appreciated.
Thanks.
You need to solve two different problems:
Creating an empty MS Access database with a structure that matches the MySQL database structure.
Extracting the data from MySQL and loading it into MS Access.
This is not easy because different SQL databases offer different structural features, different datatypes, and so on. The more complex your use of MySQL is the more likely you'll run into some show-stopper during the conversion (for instance, Access doesn't support triggers at all). Conversely if you're using MySQL as a simple data store you may find the conversion fairly easy.
To get an MS Access database with the same structure as your MySQL database, your best bet is to find a database definition / diagramming tool that offers reverse engineering and supports both MySQL and MS Access. Use it to reverse engineer your MySQL database into a database diagram, then change the underlying database to MS Access and use the tool to generate a database.
Check out Dezign For Databases which (on paper, anyway) offers the features you would need to do this.
To pump the data across, there are any number of tools. This kind of operation is generically referred to as ETL (Extract, Translate, Load).
Do you mean SQL Server? A good starting point might be to check out SQL Server Integration Services (SSIS), which can be used for transferring data around like that.
Google will also be helpful, check out the first result:
http://support.microsoft.com/kb/237980
By the way, you said ".sql" in your question: a .SQL file is a script file, which could do anything from create a database, insert data, drop table, delete data, or given the right permissions, call system procedures and reboot a machine, format a drive, send an email.. Just for ref, .SQL files aren't the storage format used by SQL Server.
While you can script your database's schema into script files via something like SQLyog, you will find that the syntax varies enough from database to database (MySQL to Access, in your case) that you can't directly apply the scripts.
With much effort a conversion script could be created by editing the script (perhaps automated with a program, depending on the resulting script size). I think you would be better served using ODBC to copy the tables (and data) and then extracting and re-applying the relationships from the generated script by hand. Time consuming, but also a one time operation I would hope.
When both systems are the same database, there are tools that can do the comparison and script generation (TOAD for MySQL and RedGate Compare for Microsoft SQL), but they don't do cross database work (at least not the ones I am aware of).
If you create a ODBC DSN, you can use TransferDatabase to import from your MySQL database. You can do it manually with the GET EXTERNAL DATA command (or whatever it is in A2007/A2010) and see how well it works. It won't get all data types exactly right, but you could do some massaging and likely get it closer to what will work best.
Is there some reason you can't just link to the MySQL tables and use them directly? That is, why do you need to import into Access at all?
Access: run query. Just make sure to adapt the SQL code since every RDMS has its own sintaxis (despite SQL being an ANSI standard).
I want to create a desktop version of my mysql installation without having to setup a server on my machine.
I want to make use of MS Access' query designer so I can produce complicated queries.
I know I can produce an SQL file but I've no idea how to create an MS Access database from it ?
I'm not going to jump on the "Access sucks" bandwagon, though it can be very frustrating at times.
Worst case, You can start with a blank Access database (mdb file, since you specified pre-2007). Open the query designer & go to SQL view. Paste in one complete SQL statement (CREATE TABLE...), and run it. Fix any incompatibility errors, paste in the next (replacing the first), rinse, repeat. Be sure to do this in such order that any dependency "sources" get created before the dependents.
There may be a batch process available, but I don't know what it is offhand.
Moving from MySQL to something like Access is heading in the wrong direction.
If you need a server-less SQL installation or package as part of your distribution (which is a pretty common requirement these days since admins don't like users to install database servers on their machines), consider SQL Server Compact Edition (CE) or SQL Lite. They're both fully SQL compliant (unlike Access) and will cause you far fewer headaches than Access (which sucks). (Did I mention that Access sucks? Big time?)
SQL CE is a .NET assembly that runs in-process with your app, and is very easy to work with. Also, db objects you create will be upwards-compatibile with the full-blown SQL Server. It also works very, very well with Entity Framework if you're into ORMs.
I've heard praise for SQLite, but haven't worked with it. If you're not on .NET, this should be a good way to go.
Links:
SQL CE
SQLite
I don't know if this is a viable option, but if you can set up a DSN to point to your MySQL server, you can then use FILE | GET EXTERNAL DATA | IMPORT to import your MySQL tables into a blank MDB/ACCDB. It's a one-time operation, but I don't know that there's any other option here. You should get the option to import the table schema only and not schema+data. You may have to tweak data types in the resulting tables, since the MySQL data types won't necessarily map directly to Jet/ACE data types.
Then you can carry the MDB/ACCDB file anywhere you want.
Am considering moving my simple ms-access 2003 client server desktop application to one with an ms-access interface and sybase 10 or 11 sql Anywhere backend database.
Why? because i want to:
- take advantage of the easy & quick way access can build forms and reports (which i am already familiar with ... meaning less learning curve for me)
- take advantage of the reliable and efficient way sybase dbs can be set up to synchronize data across various types of networks using mobilink.
I dont want to use access replication because the data will eventually grow to more than 2GB in the back end.
So,
- What are the Pros & cons of this approach?
- can i just link to the sybase database tables using a DSN or connectionstring in VBA and proceed?
- will navigating and updating/deleting records through the ms-access forms need any special considerations?
thanks for the help
Having done both, I can heartily recommend the linked table option as preferred.
In the past, I've worked with Access frontends to MS-SQL Server backends. In the main, it's the same as working with local access tables, but there are a few exceptions. I've not worked with SQL Anywhere, but MS_SQL had issues with things like Autonumber fields for instance (different behavior to Access).
I've also recently worked on an Access frontend to a MS-SQL backend, where the normal access connection methods weren't used, in favor of Table-based-functions and stored procedures...this was an absolute nightmare to code, and pretty much offset all of the upsides to working with Access as a Rad tool. If I were to do this again, I would instead insist on forgetting about Access, and using VB.Net for the frontend. Given how good MS Report Server is these days, there really is very little reason to use Access any more.
Yes, you should be able to use ODBC linked tables to your Sybase database, assuming Sybase provides compatible ODBC drivers. However, I'd suggest not using a DSN, but a DSN-less connection instead. What I do is have a DSN defined on my programming PC, and after linking the tables, I run Doug Steele's code to convert to DSN-less connect strings.
The app should mostly just work, but there are some things that may need tweaking. Don't expect any performance improvement -- indeed, it's more likely you'll lose performance. You can then examine the parts of the app that aren't performing well and evaluate how to make them work better with a server back end. Usually this involves creating views on the server, or writing stored procedures (for things such as inserting or updating records), or using passthrough queries (so that Jet doesn't touch the SQL and just passes it off to the server for execution).
This can be complicated, though I found out that it wasn't as hard as I expected the first time I ever upsized.
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.