Good Morning,
I've been asked to make changes to a custom CMS, involving the addition and deletion of form fields and corresponding database fields. The UI changes are pretty basic. However, the twist is that I don't have direct access to the MySQL database. I've only been given a .sql file. I've edited it, changing the table structures to accomodate the UI modifications. Besides the table edits in the .sql file, is there anything else I should do to it to ensure that it re-creates the database correctly?
Thanks,
Sid
is there anything else I should do to
it to ensure that it re-creates the
database correctly?
Can you request a copy of the database, or the database with dummy data, or even a script that creates the database? That way, you can take this home, and then double check your SQL file does the right thing.
Related
My new vBulletin forum is empty, and I want to encourage new users to visit, like and contribute. But first, I need to make it...not empty. As an admin, I could manually type in a bunch of threads, all from 'admin' - but that won't work. One look at either an empty website or a site filled with admin posts are equally undesirable. So I need to add hundreds of posts from hundreds of users before day one.
I assume that I should do this via the database, which I can access from phpMyAdmin via cPanel. I tried to download (export) the 'user' table with its 74 columns as a CSV table for MS Excel, but when I opened it in Excel, it was not in table form - it was all , and " in a string. If I could only see it laid out nicely in Excel, I could paste hundreds of usernames into the USER table, and and hundreds of articles into the THREAD table. I think. Am I missing something?
I am definitely going to fake it until I make it - there is simply no other way with a new website. The question is whether I have to manually do it from the front end for each user and each new thread (weeks of work), or whether I can paste them all into the database in a couple of hours.
Please help. Thanks.
Just regarding Excel, use the 'Text to Columns' tool on the Data tab to convert the CSV string into columns.
Where are you getting the content from to pre-load your forum though? If you have to make it up anyway, then is there much actual time saving in loading data in via phpMyAdmin in reality?
Assuming you have some content available from somewhere though, then you can export to CSV again from Excel and use a CSV to SQL tool (eg. https://codebeautify.org/csv-to-sql-converter though there are others around also) to generate SQL INSERT statements for uploading via phpMyAdmin or other DB tools. (I don't recall if phpMyAdmin has a SQL file upload mechanism or if you just have to paste the SQL into the browser window... have not used it for a good few years now).
I have an access database that I have been using for a while. I have been meaning to split the database for a while but hesitant to. I have many forms that link to tables. VBA code that aid in the forms and creating reports from this access database. Sometimes the VBA code will have a dynamic query that changes on certain conditions and runs a DoCmd.RunSQL.
If I split the database will all my VBA code break down as it points to the tables within my database. Do they need to be pointed to the backend or pointing towards the linked table is enough. Will the split handle this by itself?
Let me know If I was clear enough. My main concern is my forms/VBA code will stop working.
Make a backup, go to meny Database Tools, locate the Split database wizard.
Run this, and you are done.
I've just been assigned the task to create another Access DB whose data is a subset of the master DB. I didn't build the original DB and I'm just stuck in trying to create this functionality.
Depending on a Boolean value (which I will have to integrate into the DB) each entry will dictate if all the entries data will be shared or if only a portion of the data will be shared. By sharing I mean transferring the entries into a mirror DB that is located in a folder that a wider group of people has access to.
I don't know how to even start but I'm guessing that the relations structure that the person who built the DB will be helpful for when I erased an entire entry in the DB it erased all data in other tables related to my entry as well.
For added "fun" I'm suppose to manage a C.R.U.D. system for this subset in case either a person accidentally clicks on the share button (Create) and wants to unshared the data (Delete) or when part of the original gets updated and the mirror then needs to get updated as well (Updated).
I'm hoping to get a few good ideas as to how to proceed.
Limitations and Info that I see might be relevant.
-The original DB is located in a folder whose permissions are restricted to people entering data.
-Can't use third party applications that require an install.
-The mirror DB does not have to updated automatically when the master DB updates. It can be restricted to when a user clicks a button called "Updated Mirror DB". (Only if this would provide a simpler solution)
-The process can be as slow as molasses in winter as long as it is robust.
-I have decent VBA skills when it comes to working in Excel but it lacks when related to Access.
-Users who create and manage the data have read and write access to both the folder that the master DB is in and as well the mirror DB.
-Using Access 2007 - 2010
Thanks everyone for take a look at this. If you would require more info to provide assistance please just ask and I'll do my best to acquire it.
Seeing as you have decent vba, and you're limited to apps which don't require an install, I suggest you do it as an excel vba app. VBA has all the functionality you'll need to copy databases from one spot to another on the file system, compact and repair (adox), drop tables you don't need, insert/update/delete etc.
Depending on which info you need to persist to the mirror db, it may be easier to simply make a copy of the master db and delete irrelevant tables (if it's only certain tables you need to mirror). If it's a subset of data in each table, you may find the best way would be to make a template db, which is a copy of the master db but with no data, then create a vba process to copy the template db, create linked tables in this one back to the master, then run sql to insert into the local tables select (whatever data you need to mirror) from the master tables.
All of this can be done in vba, and your users end up with an excel interface which will be very familiar. Good luck.
I have an Access 2003 database using MS-JET linked tables (that is, there are two *.mdb files). The overall task is to move to SQL server. However the existing databases have multiple fields with spaces and other characters that upset both of the Access migration wizards. So the intermediate task is to make a version of the existing mdb's with updated field names.
"Simply" changing field names in the UI mdb file doesn't work, because of the linked tables being read-only in that mdb. Updating the Data mdb file field names first doesn't work because the UI mdb then throws a wobbly on startup and Access gives up.
I'm looking for suggestions, but options I can see are:
re-integrate the Data mdb back into the UI one, do the updates, then re-export the data. Seems very risky to me (system is live, don't want to play with data any more than strictly necessary).
I've looked at several answers here relating to changing ODBC details with VBA code, which is interesting, and I can see how I might be able to programmatically edit the linked tables' names. Is this going to work? Is there a better way?
Unlink all linked tables, then edit in UI mdb the remaining forms, reports, queries (but would that work??) and edit the Data mdb fields, and finally relink everything. Will it fall apart?? ... seems likely.
Any suggestions?
Ruth
I go through this process every time I take over an existing Access application -- I have to bring it up to my own standards for naming conventions before I do anything significant with it. Recently I built a quick-and-dirty utility to rename fields. It was made for me and has very little error recovery, and a UI that is ugly, but it might be faster than doing it yourself.
See what track name autocorrect offers. How Name AutoCorrect Works in Microsoft Access
Make a copy of your UI MDB, delete the linked tables, then import them (as tables rather than links) from the Data MDB. Once you enable autocorrect, Access will attempt to propagate your field name changes wherever they are used (in forms for example). Unlikely it will catch 100% of the necessary changes, but it should resolve a big chunk of them. You would then need to manually track down and fix the rest.
Once you have everything fixed, you could use that MDB version to "upsize" your tables to SQL Server. However, one huge complication is if the original database is "live" while you're making changes to the new version. If you absolutely can't take the database out of service in the interim, you could discard the data from the new tables, then use "append" queries which alias the old to new field names to pull in the latest data.
INSERT INTO NewTable (emp_id, another_field)
SELECT
[emp ID],
[another field]
FROM OldTable IN 'C:\somefolder\Data.mdb';
Finally, a warning about autocorrect: do not leave it enabled in the production version of your database because strange things can happen. The safest approach IMO is to turn it on, complete your object name changes, then turn it back off again.
You might find Rick Fisher's Find and Replace tool helpful if you need to propagate name changes through the project. I've relied on it for years (though I don't do much Access development lately): http://www.rickworld.com/products.html
I think this tool will change the names of tables and fields for you but I am not sure. I mostly used it for finding references to tables and queries in other queries, form and report properties, and VBA code.
How can I import initial table data to a .mwb file? I know that there is an inserts tab for each table, but I would like to import around 200 records and I don't want to do this by hand.
It is not possible with the modern version of MySQL Workbench. There is no way, essentially, to model data - you can only upload it to the server (not the model). The only way currently is to edit one by one which isn't practical. Even if you reverse engineer a table filed with data, the inserts table of the EER model will be blank. You'll note that right-clicking on the row of the inserts tab gives a number of greyed out options including "load from file". I suspect the team didn't have time to implement them or something. Anyway, there is a simple work around if you know phpMyAdmin, which seems to handle CSV files well, or MySQL Workbench, which I have not gotten to work at all with CSV files.
Solution:
Draw your DB model in MySQL Workbench, structure only. Place all your data in associated CSV files - I use Excel and save as CSV - very easy. Once you have your data modeled in Excel and the structure modeled in Workbench, forward engineer the DB, then use some other tool or technique to upload your Excel modeled data.
Not the greatest solution, but bug them to provide data modeling and maybe we'll be lucky in the next version.
Currently this seems not to be possible. I too was hoping to be able to Reverse engineer from the insert statements in a script file, but 1. it didn't work :P and 2. actually the documentation explicitly states that these will be ignored:
http://download.oracle.com/docs/cd/E19078-01/mysql/mysql-workbench/wb-data-modeling.html#wb-reverse-engineering
7.7.9.1. Reverse Engineering Using a Create Script
Reverse engineering using a create script is done by using the File, Import, Reverse Engineer MySQL Create Script ... menu options. Doing this opens a file open dialog box with the default file type set to an SQL script file, a file with the extension sql.
You can create a data definition (DDL) script by executing the mysqldump db_name --no-data > script_file.sql command. Using the --no-data option ensures that the script contains DDL statements only. However, if you are working with a script that also contains DML statements you need not remove them; they will be ignored.
It seems that the lesson is that we ought to handle such resources (that are too large to be manually inserted) through some other medium, such as a versioned sql file. :(