Finding it a little bit tedious migrating to the new Mysql Workbench (5.2.22) even though it has many more features than the older GUI tools. Right now I'm confused why I can't find an SQL reference when I open the Doc Library. Is there a way to access this info within the workbench, I'd prefer not to have to open a browser to access reference info on the web.
If you just want to be able to access reference material without being connected to the internet you can download the MySQL Manual for offline viewing. It is available in a variety of formats such as HTML, PDF, CHM, Man pages and a couple more. http://dev.mysql.com/doc/
Related
I'm working on an desktop app(hta) that need to access information from a database.
My challenge is that already I have the data I need in a sqlite database file. I just want to access this database file from my app then manipulate and display the results to the users.Is it possible to deploy an app like this? I'm not finding a way to access an existing database file through html5.(The sqlite database file will be created during the app installation.It is present in C:\filepath)
The solution will depend on your use case. I can see two of them.
1. Your application runs in disconnected mode (standalone)
HTML5 provides an API called Web SQL Database. It enables you to access an API for storage in the web browser. It's pretty much build around SQLite features. However, all the web browsers do not support it.
2. Your application can access a remote server
In the case you have a remote database, and your application is allowed to access it, I would suggest that you connect to your database by making requests to it. Of course, you will require to develop your own little API on the server side to access the database e.g. via XmlHttpRequest.
You can use javascript to access Web SQL databases. Remember, Web SQL is deprecated and only supported in Chrome and Safari. And Web SQL isn’t even actually part of the HTML5 specification.
For a starter's guide: HTML5 Doctor: Introduction to Web SQL Databases
I have a client who wants a control panel for the app I am developing them. The control panel is a Mac OSX application that allows the user to submit files (excel docs and such) to my MySQL database. Those files are then checked by the iOS app I have created for them.
I have no idea how to do this. I have the MySQL database all set up, and I have looked everywhere for a solution. Any help is appreciated.
I wouldn't try to connect to your MySQL database directly from your cell phone. It's a bad design for several reasons. Instead build a API on the same server as the MySQL database. It doesn't matter if you do it in java, php, c# or anything else. You might even find some product or open source project that can do this automatically. I've listed some benefits of doing it this way
It makes testing easier. You can write a test framework against your API that doesn't rely on or is using a phone.
It makes development faster. You don't need to emulate or use a phone to develop and test your table design and queries.
It gives you compatibility. When you need to change your database (and you do) you can create new APIs that the new version of the app uses while and old version still out there can continue to use the old API (that you might have to modify to still provide the same functionallity)
It gives you flexibility. If your user base grows and you might need to have replication for reads or sharded databases you build that into the API instead of into the app which is just a better way to do it.
One option would be to use PHP to handle all the database interaction.
Host the scripts on the server and just have the apps call them and get the scripts to return some sort of parseable response (I'd go for JSON).
I have never found a suitable Object-C based connector for MySQL. At this point I would suggest using a C/C++ connector. There's lots of examples of how to configure the connector for both C and C++. The hard part will be all of the data passed from the MySQL code and the Object-C code will that it will have to be in C types.
EDIT: An Example
How are you supposed to correctly use a Visual Studio Team System database project to implement version control on a sql server database?
This might seem overly generic but everything I've found so far online hasn't helped me in being able to achieve anything useful. I have managed to find functionality that appears to be similar to features that are in Redgate's tool Sql Compare but it definitely didn't seem as intuitive as their product.
From my understanding of how these db projects are supposed to work is that you're able to have a version of the database that either lives in Team Foundation Server (or inside the sql server itself) that you can check out to your local machine work on it and then check in the new changes which would allow for simultaneous development to work normally as it does for coding. Was I misinformed? Or is it just a complicated process to get setup?
Related is then how do you use it to deploy changes to the staging/production servers?
We don't use that, we simply script every thing and put it in source control like any other file and ALL deployments to prod are only through scripts pulled down from source control. I think the real key is that nothing gets put on prod except thorugh a source controlled script. Once the developer can't get his change to prod any other way (Devs should not have prod rights), there is no incentive to not put the change in source control.
Funny you should ask. I am the one responsible for getting our production databases under version control, and we're using Visual Studio Database Edition to do it. It is a fantastic tool. The very nice thing about this tool is that not only will it keep your schema under version control but it will validate your database schema as well and permit you to run code analysis against it. It also allows refactoring operations, and many other things.
Typically we work against a local development database, synch the changes back to VSDE, build the database to make sure there are no warnings or errors, and then create a deployment script for deployment to our production databases.
This is a simplified explanation of what and how we doing this, but I think it gives you a general idea of how it can be used. I'd be glad to answer any more specific questions you have.
Would you recommend working with multiple programmers on an MS Access application?
One of our MS Access application has grown to the point where the number of changes (bug fixes) and new features can no longer be handled by one programmer in the requested time frame.
We are trying to introduce version control using the undocumented SaveAsText and LoadFromText procedures in VBA to make collaboration on this application possible. Unfortunately we have already run into problems loading modified forms and reports back into Access as a checksum is stored in every form text file.
Before putting time into building an import/export application to compile text files into an Access database, we would like to hear your recommendations.
I think you should avoid this path at all cost, and try and persuade management into redevelopment.
It's a bitter pill to swallow, but this is going to need to be redeveloped sooner or later, and you are just saving them time and money.
We were using Microsoft's own version control add-in for MS Access 2000/2002/2003 for about 5 years now, and I can't remember a single serious problem. Usability of this add-in barely deserves a "B", but it must be much, much more convenient than fiddling with any ad-hoc method involving manual or semi-manual exporting/importing of Access forms, modules, etc.
We were using VSS as a version control system all the time. No problems whatsoever. However, if you have some good reasons to avoid VSS, you may have some options:
The version control add-in that we were using does not require VSS. Theoretically it can be used with any version control system that implements Microsoft Source Code Control Interface (MSCCI). For example, when we had to let somebody work on this project remotely, we used SourceOffsite by SourceGear. Access version control add-in worked with this third-party product fairly well (not without some quirks, but well enough). So, if your favorite version control system complies with MSCCI, you could try to use it.
Now that Microsoft has this Team Foundation thingy, apparently there are other options to be used to integrate MS Access with version control. We did not explore this path, though. This article may be a good start for exploring it.
Hope this would be of some help. :-)
P.S. I am not a big fan of MS Access. In fact, I rather hate it as a platform for a user front-end. If I had a choice, I would run away from it yesterday. :-) However, I must admit that existence of this version control add-in is one of the few things that makes maintenance of our old Access+SQLServer project more or less tolerable. :-))
In addition to what I already said here, I should add that the whole system works very well. The comparison process takes less than 30 minutes a week, for a team of 3 programmers. So let's describe it a little bit.
We have basically 2 versions of our Access program:
The "Developer's version", with all the stuff in it.
We each begin to work with an identical version of our developer's edition. As each one modifies or add parts of the code, we have to run some comparison routine on a regular basis. To do so, we have an object-export routine to a common "comparison" folder. An object (module for example) is exported as a text file (saveAsText command, do not work with tables, see infra), it will be compared to the existing equivalent text files in the folder. If files are identical, there is no file exported. If files are different, the new module is exported with the developer's name as an addition to the file name (if modQueries.txt exists, then modQueries_philippe.txt is created...). Of course if there is no equivalent .txt file in the folder, it will be created at first export.
At the end of the period, we would get in our folder the following files
modQueries.txt, being the first "original", last common version of the module
modQueries_Philippe.txt, with Philippe's modifications
modQueries_Denise.txt, with Denise's modifications
As the module was not modified by other developers, their export did not lead to the creation of a specific modQueries_developersName.txt file
If for any reasons Denise exported many times her module, only the last version is in the comparison folder.
We can then compare (with a "text file" comparer) the different versions and create the "updated" version of the module. We have a screen giving us the number of objects in the comparison folder, number of version for each object, and it is even possible to open the file comparer directly from the developer's interface (We use "File Compare Tool" which has a command-line mode and can then be started directly from Access).
The forms compare issue is quite special, as one of our rules is to have no specific code in our forms (please see here for more details). Forms are then only for display, so usually we do not even compare them. We just make sure that each one of them is updated by only one person (which is quite logical).
The table compare issue (we have local tables) can be only made between mdb files. As we export one text file per module, we also export one mdb file per table. We have a small routine allowing us to identify table differences at the structure level or at the record level.
After each comparison procedure, a subroutine will use all the objects available ini the comparison folder and create a whole new clean mdb file from scratch. This is the new developer's version. Every developer can then copy it on his computer and continue his work.
Developer's versions do not have numbers, but contains last client version number.
The client version, with limited stuff, automatically distributed to users
Each developer has the possibility to build a "client" mdb for final users. This mdb is created from scratch, in a way quite similar to our developer's version, but not all objects are exported. Some specific switches are turned off (special keys, access to code, etc). This mdb holds a version number as a property. The version number is used to build the name of the mdb file.
At production time, this mdb file is zipped and placed in a specific "distribution" folder. Each time a user starts the app, it will automatically check this folder to see if a new version is available. If yes, the client mdb file is updated from the distribution folder, and the app is restarted.
This distribution folder is replicated at night time with our overseas agencies. Users abroad will then be able to install the new version on the following day.
Following the direction provided by Yarik we settled on continuing developing in Access using the Access Add-in Source Code Control, the SVN SCC API Plugin by PushOk Software and Subversion. This stack provides us with seamless Access integration, full-backup and restore and an open version control system.
We had to install a hotfix to Access 2003 and make sure the default database file type matched our database file type to make it work.
We will continue to update this answer with our findings.
Have look at this thread:
How do you use version control with Access development?
Sounds like a terribly painful way to do team development. If you have any options for porting to another environment like VS2008 that would be my recommendation.
There is no easy way to work on Access as a team and even version control might be a bit tricky.
I've recently been given a MS Access .mdb database file and asked to make it usable in a Linux system. What I'm looking for is a way to convert the Access database to an open-source database such as MySQL or PostGres.
I don't have MS Office, and it's a one-time project for a volunteer organization so I don't want to spend money if it's avoidable. I'm running Vista x64, and have a Linux virtualbox, so something usable in either one will be good.
Forunately you don't need MS Access to get data out of an Access database. While there are tools like MDBTools that will read .mdb files on Linux, I've found them to be unstable for larger, more complicated databases. The best way is to use ADO or ODBC on Windows to export the data from the .mdb database into a format you can import somewhere else (like csv).
I've had good luck using DBI with Ruby, or using ADO in a Ruby script.
Following links may be useful for you.
MySQL:
access migrate
read.php?65,27115,27115
PostgreSQL:
Microsoft Access to PostgreSQL Conversion
Converting from other Databases to PostgreSQL
I used the MySQL Migration Toolkit and it worked very well for tables, even creating a reusable script. It is free and simple to use.
This toolkit is now EOL and the MySQL Workbench 5.2 replaces it.
Unfortunately, it falls over with "A problem caused the program to stop working correctly" when I try it with MS Access on my system. At the last step, of course. (Jan 16 2013)
Either MySQL or Postgres will work fine as a replacement data store for your access data. If your Access database contains Forms or Reports there really isn't a direct replacement in Open Source, and you'll either need to retain the Access front end and access the data using ODBC drivers, or code a new series of Forms or Reports in PHP or your favorite web scripting language.
I had the same problem now, and found this freeware to be exactly what I needed: http://www.bullzip.com/products/a2m/info.php
It extracted everything from the MDB file generated an SQL file I imported directly into my MySQL server.
There are two parts to the process
1) convert from Access database to scripts, there are some good options although you may need Access and potentially Sql Server too, to do this
2) Pick your target database - MySql would seem like a good fit, run it up on Linux or Windows and run the ddl and data in from the scripts.
Not sure how you can do this without Access though, do you have any idea what the schema looks like? If you do run into probs I could help out with step 1, but I don't have a Linux install at the moment.
i beg to differ: there is no need to use external tools or costly middleware. the simplest, cleanest, cheapest, fastest, safest (did i say BEST?) solution is using ODBC and integrating fully.