I created a WordPress site for a client who needed to support both English and Español versions of their content, which involved using a plugin called MultilingualPress that creates relationships between sites for each language.

I developed the site locally on my server, and then after they created some content, migrated it to their hosting service.

Continue reading

I was helping out http://www.pmi-sfbac.org whose web site was down.
The server was being unresponsive, and Larry Van Cantfort (the Director of Operations for PMI SFBAC) sent me this clue:
It appears that httpd has a lot of running processes and when I try to kill them I am unable to. THis is causing the server to sloooow way down. There are also error messages from mysqld with a corrupt table:

I couldn’t even get into the control panel to get things going, so the cleanest approach was to simply rebuild the server.
So I shut down the database and started to try and get it backed up so we’d at least save all the hard work of the volunteers.
So I tried to run the dump, with the following command that I got from the Parallels support site:

But that gave me the same error:

A quick Google search and I found the “fix” for this is to run a repair on the tables: http://www.daveperrett.com/articles/2009/06/18/mysql-table-is-marked-as-crashed/

That fixed the issue, and I was able to create the “dumpall.sql”.

Once I had ALL of the tables fixed, I simply rebuilt the server and migrated it into a new database as described in the Parallels KB article mentioned above (a lot more steps to make sure the backup was good, but once it was the newly imaged server was able to run without incident).

Enhanced by Zemanta

I’m a big fan of making people more productive by sharing data entry. In my current project, the tool we have for collaboration is Sharepoint 2007.One of our team members is really comfortable with Access development, and built a nice database for tracking the status of our document deliverables. The problem with this is that since Access is a local sort of solution, it doesn’t allow for people to make updates as they work, so we end up spending a lot of time with the database owner updating status.

The solution (in this particular environment) is to utilize Sharepoint lists. Access 2007 has a nice wizard driven approach to building Sharepoint lists, as long as the database is built correctly.

So here are the iterations I had to go through to make this work …

First pass: Diving right in, I loaded up the database to see what it looked like (how many tables, what sort of structure was there, etc). The designer did a good job of making a lot of the fields lookups, and had named all of the reference tables with the prefix of “REF” – so far so good:

So, thinking it would all work fine, I simply start the “Move to Sharepoint” button in the “External Data” tab of the Access Ribbon:

This starts the wizard, which walks you through the process of building the lists on Sharepoint. Once the task is finished, you are left with a new Access database that is linked to the newly created Sharepoint lists.

Looking at these lists I noticed something off: it didn’t appear that any of the reference tables were being used. They were there as linked Sharepoint lists, but when you looked at the data in either SP, or Access, there was no drop-down or choice to be made, they were simply text fields.

So digging a bit, and having a discussion with the developer, I found a few issues: Most of the reference tables weren’t actually setup as relationships in Access, and some of the reference tables didn’t have an ID column (an Autonumber primary key).

The wizard requires the links between tables to be relationships on autonumber primary key fields, in order to build the field as a lookup.

Looking at the base relationships, it turns out that there was only one of the myriad of tables that actually had a relationship:

In order to get the Sharepoint lists to build fields that were lookups to the “REF” tables, I would have to create new fields that linked to the primary keys in those tables. To do that turns out to be relatively simple in this case.

First I open up the design of the main table, and look for the fields that are using lookups (in the case below, Contract_Task):

Then I simply create a lookup field that has the name of the table in question (in this case REF_Contract_Tasks). First step is to insert or append a new column :

Name the new column the same as the table in question:

Choose “Lookup Wizard …” for the Data Type:

Then complete the lookup wizard:

Choose the table you are interested in (in this case REF_Contract_Tasks):

Pick which fields you want to display (typically this will just be a name field, but you can choose whichever fields you think would be helpful):

Choose the order you want things displayed:

Format the columns for lookup display (it’s recommended not to display the ID column):

Choose a name for the field (if you already typed this in, you don’t need to change it):

The wizard now asks you if you’d like to save the changes, which you should do:

Now if I look at the relationships, and hit “show all relationships”, I see the newly created link:

Right click on the relationship line to edit the relationship:

And I typically just check the “Enforce Referential Integrity” box to make sure it is an identifying relationship:

Once that is done, I can either build an update query, or copy the contents of the original row to the new one in datasheet view. For the purposes of this database, there aren’t that many rows, so a simple cut and paste works fine:

Hit ctrl-C or choose “Copy” from the menu:

Select the new row, and paste the data there:

Repeat for all of the other rows in the table that have some query in the lookup tab …

Now in a couple of cases, I got prompted for which field to use to establish the relationship. These are the tables that didn’t have an autonumber primary key. The fix for this is relatively painless (once you discover which tables have the problem).

Just add a new field to the table that has a Data Type of Autonumber, and make it a primary key.

The trick with this is that the primary key won’t likely have the same numbers as the original ID column, and you can’t create an AutoNumber column with data in it. So in order to get the new field updated, the easiest thing to do is create an update query and edit it to use the old join values.

Do query wizard, and choose the columns in question, in this case Deliverables, and REF_Projects. Since you created a relationship with the new REF_Projects field on the Deliverables table, you should end up with something like this:

In theory you should be able to edit the relationship in the GUI by dragging it around and/or right clicking on it. I’ve actually had limited success with this, so I tend to simply add the column I want to update (REF_Projects) to the query, then hit the button on the Design tab of the ribbon that says “Update”:

Then switch to SQL view in order to modify the join properties more easily:

The query so far will be something like:

UPDATE REF_Projects
INNER JOIN Deliverables
ON REF_Projects.newID = Deliverables.REF_Projects

SET Deliverables.REF_Projects = [REF_Projects].[newID];

And you want to update it with the old columns from the lookup query that was in the original table, so in this case it becomes:

UPDATE REF_Projects
INNER JOIN Deliverables
ON REF_Projects.ID = Deliverables.Project_Level

SET Deliverables.REF_Projects = [REF_Projects].[newID];

Then run the query and the values in the two fields should look relatively the same in the datasheet view (since they are now both pointing at the same rows.

Then another one that threw me off was one field that had a different column heading than the field name. When I got to the “Doc_Type” field, I didn’t see it in the Datasheet view. Turns out it had a value in the Caption area of the field definition:

So in the datasheet view it showed as “NDCP Standard”:

This field also has another interesting challenge – the values didn’t all match up with the values in the lookup table (REF_Doc_Type), so when I did my cut-and-paste trick I got the following error:

So looking at the REF_Doc_Type table, I was able to figure out that there is no row that is named “Standard” (likely it had been changed to “Program standard” at some point, and since this column stores the actual value, there is a disconnect).

So in this case, I chose to simply update the current column values to match the one I thought it should be with an update:

After that my cut-and-paste from the “NDCP Standard” field to the “REF_Doc_Type” field went without a flaw.

This same trick needs to be applied to any of the tables that will be worked directly with (typically those that contribute to forms) in order to make sure all of the proper links are built.

Once you have the links built, you want to rename the original table and build a view (in Access this is called a Query) with the same name that has all the joins you need in place. So after you rename the table, just build a simple query with that table in place (I use the wizard and make sure I include all of the fields):

I have been running my development for VolunteerCake with a database on my Windows box which sits in my office with my Mac. I went to meet some people at a coffee shop, and realized that I couldn’t show them the app running on my MacBook because I was no longer on the same subnet with my Windows box, so I decided to move the database to the Mac to allow me for this.

Since I had everything in place to run Cake on my Mac except for MySQL, the first step was to install MySQL. This turns out to be pretty painless. Just grab the DMG from the MySQL site, and voila, new MySQL running on my Mac. Checked everything out using the MySQL administration tools, and it all looks good (I can access the DB, set up users, etc.)

Next I need to put the data in the database, so I just do a quick export from the phpmyadmin page on the PC. I end up with a file that is the SQL needed to replicate the entire database on my Mac. I run this SQL into the Mac MySQL, and now I have an exact copy of the database on my Mac.

After that, I go to the SQL administrator tool and make sure I have the user set up to give access to that database and make sure the username and password are the same as I was using on the PC (if I were more of a DBA, I’d probably have done this with command line MySQL, but I like GUIs, especially for things I don’t do every day, and the MySQL tools are pretty cool).

Then I need to change my database.php to point at the local database in order for VolunteerCake to get the data from the Mac. This should be as easy as changing the name of the host name to ‘localhost’ from ‘monet’ since I’ve set up the user and access to the database exactly the same as what I had on the PC.

Finally, all that’s left is to fire up the same URL that I have established for my app on my Mac (http://test.lctd.org/VolunteerCake) and … wait, that didn’t work. It says it can’t find the table acos for the Aco model …

Weird, the table is there, I can connect just fine, what could this be? A quick trip to the IRC channel, and I get the suggestion of clearing my cache. OK, try that … But hit the URL again and no change.

OK, now I’m confused, so I try running ‘cake bake’ … Now something interesting: I get an error that tells me that it was unable to connect to /var/mysql/mysql.sock – what does that mean? I thought I was connecting with a TCP socket, why does it want a file? Is this some sort of file permissions issue ?

Back to the IRC chat for some guidance, thinking maybe it’s a common problem, a permissions issue or something, of course they tell me to do exactly what I’d tell somebody else to do: verify that you can connect from PHP first. Good idea – so I whip up a quick connection test page, and get the same error. So now I’ve confirmed that it’s a PHP problem, and not a Cake issue.PHP can connect to a remote DB, but not the one on my local Mac …

Now it occurs to me that I often have problems that end up being related to the open source software that came bundled with the Mac, so I do some Google searches on PHP connection to MySQL for Mac OS X, and with the connection error messages. Eventually I find what looks to be the issue: for some reason the MySQL configuration sets the socket file to /tmp/mysql.sock but the PHP that comes with the Mac is looking somewhere else (at /var/mysql/mysql.sock to be specific). So I basically have three choices, edit the php.ini, edit the mysql config file, or build symlinks to make the file accessible at both locations.

I decide to change the php.ini file, which turns out to be another excercise in hunting, since Mac OS X likes to hide the files you’d expect to find in the /etc directory. After some more Google searches, I find that the PHP5 install that comes with Leopard puts the php.ini file into /private/etc, so I edit that file, changing the part of the file that looks like the following:

To be:

In order to have PHP find the mysql.sock in the location that MySQL is actually creating it. Check my URL again, and voila, everything is working !!!

So, to make a long story even longer, I relearned that mixing actual open source with vendor open source is often problematic. It was suggested by at least one person (Mark Story) on the IRC channel that the best way to set up for Cake development on the Mac is to use MacPorts, since then you end up with matching versions of the software all in a “normal” open source location.

Enhanced by Zemanta