Need PHP Script to Backup/Restore a PowWeb MySQL [Archive]

View Full Version : Need PHP Script to Backup/Restore a PowWeb MySQL

RayRoy

3-10-06, 05:34 AM

Note: to Moderator: I try this into PHP forum. Not SQL.
But you can move it to SQL if you think better. Thanks.

Does anyone have a simple PHP script capable of doing a MySQL
database dump, and saving it as a SINGLE file .DMP(?) into my
server webspace, as a non-.GZ, non-.ZIP, non-.TAR, non-.SQL?

It's a small database, less than 2 MBytes. I do not need to
edit it, nor spend time downloading it all the way to my HDSK
using a slow dialup modem.

Next question, is a similar PHP script that can push the exact
same file back INTO my PowWeb MySQL database. Same format. Same
filename. Taking it right from the same subdirectory where the
above mentioned PHP script deposited it?

All I want is the ability to Backup/Restore MySQL using PHP.

Good help or suggestions would be appreciated. Thanks.

Note: I need this because nothing else works using my older
browser versions.

BerksWebGuy

3-10-06, 09:21 AM

See this thread...its a sticky in the mysql forum:
http://forum.powweb.com/showthread.php?t=60555

mitchind

3-10-06, 11:01 AM

Moving to MySQL forum - see the Stickies at the top of this forum

RayRoy

3-10-06, 11:53 AM

Hello BerksWebGuy

Thank you for the link. It looks like what I need, if I modify it
as shown below, making separate BACKUP and RESTORE versions.

I have four questions:

Would 755 be adequate for the DIRECTORY permission?
Would I need to create a dummy-file first and give it 755 too?
Could you guestimate the largest DB size this could safely handle?
Your permission to modify your script as shown below, and use it?

================================================== ==================
================================================== ==================

BackUp.php: Note: Enter appropriate db and user info first.
===========
===========
<?
$day = (date("d"));
$filename="/www/U/USERNAME/dbbackup_$day.sql";
if(file_exists($filename))
{
unlink("$filename");
}
system("/usr/local/bin/mysqldump --opt --no-create-db --user=MYSQLUSERNAME --password=MYSQLPASSWORD --host=MYSQLXX.powweb.com DATABASE_NAME > $filename",$result1);
$size = filesize("$filename");
$runtime = (date(" F d h:ia"));
$message .= "The DB BACKUP has been run.\n\n";
$message .= "The get return code was: $result1\n";
$message .= "Size of the BACKUP: $size bytes\n\n";
$message .= "Server time of the BACKUP: $runtime\n\n";
?>

================================================== ==================
================================================== ==================

Restore.php: Note 1: Note: enter appropriate db and user info first.
=========== Note 2: Enter filename on line 3 (created by backup).
===========
<?
$day = (date("d"));
$filename="/www/U/USERNAME/dbbackup_$day.sql"; // manually enter filename first
if(file_exists($filename))
{
unlink("$filename");
}
system("/usr/local/bin/mysql --user=MYSQLUSERNAME --password=MYSQLPASSWORD --host=MYSQLXX.powweb.com DATABASE_NAME < $filename",$result2);
$size = filesize("$filename");
$runtime = (date(" F d h:ia"));
$message .= "The DB RESTORE has been run.\n\n";
$message .= "The put return code was: $result2\n\n";
$message .= "Size of the RESTORE: $size bytes\n\n";
$message .= "Server time of the RESTORE: $runtime\n\n";
?>

================================================== ==================
================================================== ==================

PS: Should I remove this portion in the Restore.php? (Since I will be
manually entering the filename to be used for restoral)
============================
if(file_exists($filename))
{
unlink("$filename");
}
============================
Thanks again for your quick and useful solution.
RayRoy

BerksWebGuy

3-10-06, 12:23 PM

Answer to your questions:
1. yes
2. no
3. no idea, but in the same thread, there is a shell script that can handle more if you run into problems (posted by extras)
4. of course
PS. you can remove the delete

Good Luck :cool:

RayRoy

3-10-06, 01:13 PM

Hello again, BerksWebGuy

Okay, fine I will try it later and report back my results
into this thread.

I have changed the script additionally, to test for typo's
or missing filename to use for Restoral, and to exit:

If this set of BackUp/Restore PHP's work good, I can
further modify them to become a single PHP "form" which
will prompt for the DATABASE; USERNAME; PASSWORD; FileName
etc and have an upper and lower section. Upper for BackUp,
and the lower for Restoral.

Each would have separate input fields, and button to push.

If the Moderator could leave this thread unlocked, I can
Post that combined version for anyone's use, later.

Thanks again. RayRoy

============= modified for filetest/exit ========
Restore.php: Note 1: Note: enter appropriate db and user info first.
=========== Note 2: Enter filename on line 3 (created by backup).
===========
<?
$day = (date("d"));
$filename="/www/U/USERNAME/dbbackup_$day.sql"; // manually enter filename first
if (!file_exists($filename)) // if filename not-found, then exit.
{
$message .= "Filename not found -- Aborting Restoral";
exit;
}
system("/usr/local/bin/mysql --user=MYSQLUSERNAME --password=MYSQLPASSWORD --host=MYSQLXX.powweb.com DATABASE_NAME < $filename",$result2);
$size = filesize("$filename");
$runtime = (date(" F d h:ia"));
$message .= "The DB RESTORE has been run.\n\n";
$message .= "The put return code was: $result2\n\n";
$message .= "Size of the RESTORE: $size bytes\n\n";
$message .= "Server time of the RESTORE: $runtime\n\n";
?>

======================= end ==============================

RayRoy

3-10-06, 05:23 PM

My Thanks, again, to BerksWebGuy for steering me to his MySQL
core PHP script.

I have made it more UserFriendly for the average person who
is all thumbs, like myself.

Later, when I have more time, some other day, I will combine
these two into a sigle PHP file with Prompting entry fields
for your SQL info, filename etc.

And a button to push for "BACKUP" or another for "RESTORE".

To use this, you FTP-upload both these PHP scripts into your
webspace into a subdirectory which has permission 755. Is no
need to set permissions on either of these two PHP files, nor
on the subsequently created backup files.

Just be sure they are all in the same (anyname) subdirectory.

I've tested it and it works fine as modified and shown below.
My databases are not huge. It took less than 5-seconds to run
on a 52 KByte database.

RayRoy
================================================== ==============
<?php
# BackUp.php: Note: Enter appropriate MySQL and User info first.
# ===========
# ===========
$SQLserv = "mysqlXX.powweb.com"; // enter PowWeb MySQL servername
$SQLname = "XXXXX"; // enter MySQL Database Name
$SQLuser = "XXXXXXXXXX"; // enter MySQL Username
$SQLpwd = "********"; // enter MySQL Password

# output FileName will be "yymmddhh.dmp" of the current date/time

$day = (date("ymdH")); // or you can change this date/time format
$filename="$day.dmp"; // or you can specify any FileName you like
if (file_exists($filename))
{
unlink("$filename");
}
system("/usr/local/bin/mysqldump --opt --no-create-db --user=$SQLuser --password=$SQLpwd --host=$SQLserv $SQLname > $filename",$result1);
$size = filesize("$filename");
$runtime = (date(":: l :: d F Y :: H:i:s A ::"));

echo "SQL Server Name: $SQLserv <hr> ";
echo "SQL Database Name: $SQLname <hr> ";
echo "SQL User Name: $SQLuser <hr> ";
echo "SQL Password: $SQLpwd <hr><hr> ";

echo "MySQL BACKUP Created OK: $filename <hr> ";
echo "The get return code was: $result1 <hr> ";
echo "Size of the BACKUP file: $size bytes <hr> ";
echo "Date/Time of the BACKUP: $runtime <hr><hr> ";
?>
================================================== ==============
================================================== ==============
<?php
# Restore.php: Note 1: Enter appropriate MySQL and User info first.
# =========== Note 2: Enter filename (previously created by backup).
# ===========
$SQLserv = "mysqlXX.powweb.com"; // enter PowWeb SQL servername
$SQLname = "XXXXX"; // enter MySQL Database Name
$SQLuser = "XXXXXXXXXX"; // enter MySQL Username
$SQLpwd = "********"; // enter MySQL Password
$USEfile = "YourFile.dmp"; // enter filename to RESTORE FROM

$filename=$USEfile;
if (!file_exists($filename)) // if filename not-found, then exit.
{
echo " <hr><hr> Filename not Found -- Aborting Restoral <hr><hr>";
exit;
}
system("/usr/local/bin/mysql --user=$SQLuser --password=$SQLpwd --host=$SQLserv $SQLname < $filename",$result2);
$size = filesize("$filename");
$runtime = (date(":: l :: d F Y :: H:i:s A ::"));

echo "SQL Server Name: $SQLserv <hr> ";
echo "SQL Database Name: $SQLname <hr> ";
echo "SQL User Name: $SQLuser <hr> ";
echo "SQL Password: $SQLpwd <hr> ";
echo "DMP FileName: $USEfile <hr><hr> ";

echo "MySQL RESTORED OK using file: $filename <hr> ";
echo "The get return code was: $result2 <hr> ";
echo "Size of the RESTORED file: $size bytes <hr> ";
echo "Date/Time of the RESTORAL: $runtime <hr><hr> ";
?>
================================================== ==============

RayRoy

3-11-06, 04:43 AM

Deluxe Version completed and D/L is ready online: Anyone wanna Beta Test it?
Check out the ScreenShot. You'll LOVE it. It's free. And it works perfectly.
It's just a single .PHP file, with dual BackUp/Restore capability. Very FAST!

If you hate MySQL database restorals, this one is for you. Enjoy!

RayRoy

See updated links in newer thread
http://forum.powweb.com/showthread.php?p=365402

(Both URLs are case sensitive.)
(The READme file is the top few lines inside the PHP script.)

extras

3-11-06, 10:41 AM

Nice contribution. :)

If the DB gets too big for PHP script, you can use this one.
It can handle compression/decompression to/from zip/tar/tar.gz/tar.bz2,
and support individual table backup and restore.
http://forum.powweb.com/showthread.php?t=57758

MiniSqlAdmin also offers easy backup/restore feature in Admin menu.
Once you add the DBs, it remembers the parameters.
It allows you to do any MySQL query (and save the result in a file), too.
http://check-these.info/MiniSqlAdmin.html

RayRoy

3-11-06, 05:35 PM

Thank you for your kind comment.
I guess we are all here to help other PowWeb Users, the best ways we can.

Moving on:

You said:
[quote]
"If the DB gets too big for PHP script, you can use this one."
[unquote]

I will assume the "you" word literally, that you are giving me
permission to use, or evaluate, your many nice scripts. Recall,
you had revoked that permission in a previous exchange.

Please let me know if you still feel otherwise. Thanks.

As-for the issue or limitations of my script for larger MySQL
BackUps/Restores, I have no idea yet what sizes -if any- it
could not handle. It seems to me the engine is no different
than anything else that uploads/downloads .DMP format dumps.

And, since my script does not require physical off-server
downloads (by modem) the files remain (intra-server backbone)
on the PowWeb server(s) and hence extremely fast access in or
out of the SQL server. Someone please correct me if I'm wrong.

Anyway, we won't know until a few users beta-try it and give
us -all of us- some feedback here in the forum of their results.

It would be helpful to know what size files work, and what size
-if any- exceed it.

...because if I knew, I could imbed file-size checks/error msgs
to prevent unnecessary hassles by those users.

Thanks again, @extras for all the help you give folks in these forums.

RayRoy

extras

3-12-06, 12:01 PM

I told you so because you didn't understand how things work here and acted badly.
If you know that this is a place to have fun by solving problems and informing/educating each other,
there is no problem.

As for the script, it will fail because of PHP, not because of the commnad or logic (as it's a simple script).

PHP has builtin time limit of 30 seconds.
Unless you set the limit longer, your script will fail when mysql command takes more than 30 secs.

Also, PHP buffers output until it finishes processing eveything.
And the browsers and maybe Apache timeout when there is no output for certain period (60 secs?).
So, unless you do something to keep sending some data, when the mysql command runs for more than
1 min or whatever the limit of browsers/Apache, it may end up in 500 error.
This can be avoided by using ob_flush(), putting the command in the back groud and sending some data periodically.

And PHP uses more than 9MB of memory just to start, while shell script uses less than 400kb.
So, if someone tries the script many time, somehow, it may create the situation of resource abuse much easier.

But you don't have to think about these as long as your DB is very small like what you have, currently.

RayRoy

3-12-06, 04:48 PM

I have just finished some extensive tests using the PHP4SQL.php utility.

I currently have five MySQL databases. The smallest was 3742 Bytes dump file.
Another was 52 KBytes dumpfile. Another was 360 Kbytes. Another was 402 Kbytes.
All of these BackUp/Restore perfectly is less than 5-seconds each...

But what I didn't mention before, is:

My largest Forum, that has 163 Pages of approx 300 Kbytes per page
archived in MySQL. The MySQL dump file was 20 MegaBytes. And it was able
to BackUp and Restore it perfectly. Still in less than 5 seconds.

I was also able to FTP that BackUp over to my Mirror site (not on PowWeb)
and use the same 20 MegaByte file there to Restore that MIRROR Forum.

I am confident this Utility will work well for an average user.

@extras points are well-taken. Use whichever utility you find
that suits your needs and does everything right. MySQL can be fun.
But usually isn't.

RayRoy

extras

3-13-06, 10:40 AM

It's not proportionally related to the size.
It's a time related problem.

And it varies with the type of DB you have.
Simple DBs with a few large records would be pretty quick.
Complicated DBs with lots of records may take much longer to process.

Also, Sunday afternoon is a good time to do it, as DBs tend to be more loaded during weekdays.
Maybe your script can handle 100MB DB if it's a simple structure and MySQL server isn't busy.

In addition to this, there is a time limit of CPU (20 CPU seconds, which isn't same as our time).
And even MiniSqlDump will fail with very large DB, especially if it's compressed.

But there are walk arounds, like splitting file, and feeding one by one.
I think Halfabee or someone wrote a script to do it automaically, too.

RayRoy

3-13-06, 11:28 AM

What we need is someone with a very-very large MySQL DB to test it.

Possibly you have one, used for testing your scripts, that
would not be put-at-risk should it timeout.

ie: you could easily restore it back to normal using your MiniSqlDump.cgi

C'mon extras... I think alot of viewers would like to hear
of more real-world test results. I can't believe so few folks
are responding.

I'll bet you a Cup of Coffee that it would handle 100 MBytes
without a glitch. An offer you can't refuse?

RayRoy

extras

3-14-06, 08:52 AM

As I said in the previous post, it also depends on the conditions other than the size.
Probably I can create a complicated but small .sql , for exampple.

But why should I do that?
When your script fails, you can try MiniSqlDump as it's more resistant and informative.
If both fails, you may have to split the .sql file.

The only thing average users should retain is to avoid running the script many times within short period.
(Some people are really impatient, and click many many times on the button, only to create resource abuse situation. And we've already seen that.)

Also, I don't want to put stress on Web server nor MySQL server.
It may even shut down my account because of resource abuse.

So if you want to do very heavy tests, please do it on your own machine.

RayRoy

3-14-06, 04:49 PM

The issue of "resource abuse" is one all responsible PowWeb Users wish to avoid.
But I believe the spectre of that in the case of this script is overstated, and,
warrantless negativism.

Lets look at the facts:

BerksWebGuy has used the two core lines of this database-dump/database-restore
for apparently a lengthy time, on a Chron schedule. Probably nightly. He could
enlighten us on the size(s) and nature of his databases. But I'm sure he has no
instances of resource abuse.

I myself use it nightly to BackUp my 20 Megabyte Forum database of Priceless
Posts, with no glitchs (nor abuse complaints) of any kind. In less than 5 sec.

Let's look at the script itself:

PHP-wise, there are only two lines of code which comprise the core engine, and,
only one of those would be in-use for either a BackUp -or- Restore operation:

BackUp Mode:
============
<?php
system("/usr/local/bin/mysqldump --opt --no-create-db --user=$dbuser --password=$dbpass --host=$dbserv $dbname > $filename",$result1);
$size = filesize("$filename");
?>

-or-

Restore Mode:
=============
<?php
system("/usr/local/bin/mysql --user=$dbuser --password=$dbpass --host=$dbserv $dbname < $filename",$result2);
$size = filesize("$filename");
?>

To say that one line of PHP code, which executes in milliseconds, could possibly
"overwork" the PHP engine at PowWeb is laffable. It cannot be that skimpy nor
time-limited to prevent non-existant "resource abuse". One of PowWeb's engineers
is certainly invited to come into this thread and confirm, or deny, that.

Let's look at them further in detaiL:

system("mysqldump [options]);

Simply invokes the system's mysqldump.exe not-unlike a shell (cgi) would do.

-or-

system("mysql [options]);

Does likewise, invoking the mysql.exe at fast system-level. PHP has handed the
process over-to the system. PHP is out of it. No PHP CPU time is being consumed.

Let's look further at the "issue" of "re-writing" or "re-reading" many intricate
SQL tables and data in the Dumping, or Restoring, process:

It becomes simply a straight-shot serial file transfer. Indeed, all the tables
are LOCKED during the process, by the .exe command line option: (--opt) used.

A Database DUMP (.DMP) file is significantly different from a (.SQL) file which
is a structured "set" of internalized files much like those in a .ZIP file with
imbedded subdirectory structure. SQL Format uses alot of SQL engine processing.

A .DMP file is none of that. It is a single file, which can be read in an ASCII
editor. It contains nothing more than the MIRROR of actual table structure(s) as
it's header, followed-by the raw data, all of which is (or will be reinserted)
in one quick fell-swoop. No table-rewriting is being done. That has already
been done (over time) by the application (forum, etc) which wrote the tables
one by one in the first place, long ago. Dumping a MIRROR (.DMP) of those does
not involve any RE-processing of them whatsoever. In, nor, out.

Again, let me stress that the .DMP file output (or input) consumes *NO* resource
of the SQL engine in re-writing any tables, nor raw data. It simply replaces all
that was found there, as is, no questions asked. No (-zero-) SQL re-processing
of any of that .DMP data is performed. None. Whatsoever.

And hence the reason why this script is so efficient, fast, stable and accurate.

To denigrate it with false issues, unproven, with nothing more than hypothetical
conjecture does it a disservice, in my opinion. It is warrantless critiscism.

PowWeb could easily put these false issues to rest, by running some easy tests
which I'm sure, would pass with flying colors, and not jeopardize anyone's Web
status nor cause any "resource abuse" actions against any members here.

Again, I state categorically, that a PHP script which uses less than half-second
of run time, and less than 5 seconds of SQL input-output as serial file-dumps
cannot possibly overload either one, nor cause any complaints.

What we need here, is some objective PowWeb testing. Not subjective hyperbole.

RayRoy;)

extras

3-14-06, 05:24 PM

RayRoy, you are talking things you don't really know, again....

Cronjobs run on FTP server, and it has different settings.
The situation isn't the same on cronjob.

Also, there is no such thing as mysql.exe on PowWeb.
On unix, executables doesn't have to have specific extension like .exe, .com.

And dump/restore is using sql file, which can have .dmp or any extension.
Some DB may have complex indexes and restoration may consume fair amount of resources unlike you insist.
Dumping is similar to basic query, and it consumues resources, too.

And I didn't said the system() functoin overload PHP.
I was talking about the resource abuse situation when many PHP (or any other big) processes get accumlated.

Don't ruin the thread with silly arguments.
I've told you that it's because of the PHP (memory size, and time limits), and not because of your scripting.
I've praised your effort, gave you reputation points, informed you of things probably you didn't know.
And I've told you that my script will fail under certain conditions, too.

Can you understand that I'm not denigrating your effort or script?
Cool down a bit, pal. ;)

Don't go into "demanding mentality", again.
Have fun. :)

extras

3-14-06, 06:46 PM

I did some tests to satisfy your curiosity. ;)

I used a DB of about 70MB, which I've already used for testing before.
(It's a phpBB DB. search_words table alone takes 6 seconds to dump.)
It took about 17 seconds on a server with very light load.
It used max 77% CPU, which is very high, but not necessarily sustained figure.
It took about 14 CPU seconds to finish dumping (both with and without --opt).
If the load figure is higher and takes twice longer, PHP script with the default time limit would fail.

Judging from this result, I'd say the maximum size of DB we can dump with mysqldump is about 120 to 150MB at optimal condition.
(This is applicable for both your script and mine.)
And it's mostly dictated by the CPU time limit of 20 seconds.

Also, strictly speaking, the task of dumping 120MB DB might be considered as a resource abuse.
TOS says more than 10% CPU for 1 minute or more.
At light load condition, the task will only take about 30 seconds, but using high CPU percentage.
At higher load condition, it will take longer at lower CPU usage.
Fortunately, PowWeb doesn't apply this rule always very strictly.

This is the output of ps, just before finishing.
2:32PM up 200 days, 22:29, 2 users, load averages: 1.62, 1.45, 1.61
USER PID %CPU %MEM VSZ RSS TT STAT STARTED TIME COMMAND
zzzzzz 33131 69.6 0.1 3612 1712 ?? R 2:31PM 0:13.39 mysqldump --opt -uzzz -pzzzzzz -hmysql99.powweb.com zzz
zzzzzz 33282 0.0 0.0 392 228 ?? R 2:32PM 0:00.00 ps uxww
zzzzzz 33126 0.0 0.0 696 336 ?? S 2:31PM 0:00.02 /bin/sh minisqldumpzzz.cgi

If you invoke mysqldump from PHP, it will use 9.7MB of memory, in addition.
zzzzzz 33405 0.5 0.2 15156 9740 ?? S 2:20PM 0:00.15 php4
This isn't a big problem when things go well and the job terminates rapidly, though.
If the processes accumlate, it can cause memory related abuse situation.

I may do similar tests for restoration, if I feel like so. :)

RayRoy

3-14-06, 07:06 PM

LOL: "demanding mentality". Who? Me? I carefully worded it politely:
"PowWeb's engineer is certainly invited to come into this thread"

It's an invitation they shouldn't refuse, but probably will.

You know, my friend, I wrote this PHP script and presented it here
for Peer Review. Yet, no Peers have come forth to Test/Review it.

That's very discouraging, to me. But no disaster. It works for me.
It probably would work fine for most others. It could be very helpful.

Anyone can see that MySQL BackUps/Restores are one of the biggest issues
here in the PowWeb forums. Page after page, thread after thread, of users
unable to do them. This was intended as an easy, helpful, alternative.

BTW: In my jargon, any .executeable is visualized/written as an .EXE and
you're right, I know nothing. About UNIX. MySQL. Nor PHP.

Keeping my cool, I am. Not easy at 65, but I can. Trust me.

Let's laff at this final quip:

Peer Review, when No Peers come forward, must mean it's Peerless Software.

I'll buy you that Cup of Coffee anyway. Go enjoy it. Send me the Tab.

Thanks again.

RayRoy

RayRoy

3-16-06, 10:44 PM

Hello @ extras and All Reading this Thread...

I just dropped in to edit my Post here #8 (above) because I have rearranged my download link
for this script. But for some reason, the "edit" button does not appear for me, and I've
tried several Browsers including this one now, MSIE 6.0 in Win~XP.

Anyway, The new links for downloading it should be as shown here:

================================================== ===========
ScreenShot: 23 kByte .GIF
http://OS2Eagle.Net/RayRoy/DOWNLOAD/php4sql.gif

DownLoad PHP4SQL.PHP v1.0 -- 26 Kbyte .ZIP:
http://OS2Eagle.Net/RayRoy/DOWNLOAD/download.php

(Both URLs are case sensitive.)
(The READme file is the top few lines inside the PHP script.)
================================================== ===========

While I'm here, I can Thank you for the tests you made recently, although as I read it, your
test was using your MiniSQLDump.CGI script, and not my PHP4SQL.PHP script in question here.

I've been thinking some of the items you mentioned earlier about resource abuse and want to
offer some comments:

(1) The 9.7 MB overhead of running my PHP script is not unique to it. ie: That's a shared
or common memory resource used by any and all PHP scripts invoked in PowWeb space. Whether
it's my PHP script, or someone's tiny PageHitCounter. The 9.7 MB is constant overhead to have
PHP available for all PowWeb users. Is it not? So, my script cannot abuse it any more than
any other PHP script in-process.

(2) The issue of overloading PowWeb's MySQL or MySQLDump resource also begs clarification.
Is it not true that nomatter which application a person uses here to obtain a Dump or make
a Restoral, is going to essentially use the identical System-level .executeable. Whether it's
PowWeb's SQL tools; thier frequent nightly backups; PhpAdmin for MySQL; your MiniSQLDump.CGI;
or (gasp) my little PHP4SQL.PHP script? All accomplish the same thing, using the same resource.

Well, Thanks again for all your input here. Folks will just have to decide for themselves what
BackUp/Restoral methods work best for their particular MySQL requirements.

It would have been nice if someone could have come forward and made some definitive tests.
I will certainly look forward to any that may be documented further into this thread.

RayRoy

IanS

3-17-06, 07:24 AM

mitchind

3-17-06, 12:08 PM

I've edited his previous post to point to the links in the newer one.

RayRoy

3-18-06, 04:19 PM

The "edit-link" @mitchind has showing now at my Post #8 does not seem to work right...

It takes me to a LogIn-required link that wants to change my Post #20 (which is already okay).

ie: it isn't giving me an Edit screen for The Post #8 which has the older download link.

It isn't important, since my Post #20 is adequate for the new download link.

RR

mitchind

3-18-06, 04:43 PM

Fixed.