If you find that the really handy Excel spreadsheet import feature for MySQL is missing in PHPMyAdmin, it's because it has been removed. According to the PHPMyAdmin changelog:
3.4.5.0 (2011-09-14)
- [core] Remove library PHPExcel, due to license issues
- [export] Remove native Excel export modules (xls and xlsx formats)
- [import] Remove native Excel import modules (xls and xlsx formats)If you're importing Open Office / Libre Office Calc files or Excel spreadsheets into MySQL using PHPMyAdmin, you might have run into the occasional case where the process hangs with either a partially imported set or no records at all. After some messing around, I have found that this usually happens when there's a problem with the input data. In my case, this usually stemmed from duplicate primary keys or similar issues. Unique keys were detected fine.
In other words, PEBKAC.
If you have ever pasted data into Calc in Open Office, you'll notice that any hyperlinks in the input data will be retained as hyperlinks rather than reduced to plain text. While this might be beneficial behaviour to some, it wasn't for me this afternoon. After a little digging around, I found that an easy way of removing the hyperlinks is by highlighting all the affected cells, right-clicking and choosing the Default Formatting option.
The associated CTRL + M shortcut (as seen in the Format menu) did not work for me.
If you run into the following error message when attempting an iptables-restore < my.rules:iptables-restore v1.4.8: no command specified
then the problem is that you have very likely just copied and pasted stuff into my.rules which has led to some dodgy line-breaks terminating blank lines in the file.
On a server I am working on right now, I installed a PHP application and attempted to run it. However, I ran into a "500 Internal Server Error". Upon further investigation by checking the logs, I found the following errors in the Apache error log:
I currently work with an SVN checkout which tracks a separate GIT checkout (for reasons of managerial short-sightedness). When I update my git checkout, I find that the SVN checkout does not like the fact that files deleted by the git update have effectively been removed from the SVN checkout without the use of svn rm. Consequently, it is impossible to commit the updated checkout into the SVN repository.
Earlier today, I found myself working with an SVN checkout. As it happened, the repository that the files had been checked out from was no longer responding and upon enquiry, I found out that it had been moved to a different URL. Now, while I could have just as easily created an entirely different checkout of the files using the new URL, considering the local customisations, I looked to see if I could just do something like a live switch. As I found out after some mucking about, switch is certainly the operative word.
On a new installation of GVim (in Windows 7), I ran into the following curious error whenever I tried to open a new document for editing:Vim E303: Unable to open swap file for "[No Name]", recovery impossible
According to friendly chap on IRC, this is caused by a temporary directory bug and that it can be fixed by adding the following directive to the _vimrc file:set directory=.,$TEMP
I work extensively on a Windows desktop. However, I do SSH into Linux servers often and I do so using PuTTY, a free and open source client. Everything works peachy. However, I recently had occasion to work extensively with some Unicode source data and I found that there were times when I thought that there were encoding issues with the data as they were not being displayed correctly on my screen.
It is often important, especially when dealing with databases and such, that files are stored in the correct character set. Failure to do so can result in illegible displays or even data corruption. Checking the character set of a file in Linux can be accomplished using the file command:
Jubal@Stranger:$ file migrate1.csv
migrate1.csv: Little-endian UTF-16 Unicode English text, with CRLF, LF line terminators
Jubal@Stranger:$ file migrate2.csv