Forced classic to v7.1 threads import, because the new PHP broke php on classic 672.

Win2k3 server, MySQL latest, PHP latest.

I followed all of the instructions for Windows servers on permissions, although I must say they were extremely lacking, and read like a unix guy wrote them.
(there is no execute flag in windows, you have to use IIS admin to set that directory as executeable)

In any case, tables all setup ok...

But when I ran the classic import, I get a permission error writing to the image directory, where it appears to be grabbing my additionally added graemlins.

If I give IUSR full write access to the image dir and it's subs, the script completes just fine.

Do I need to leave this write permission in place? Or is this just required during the import of the gfx files?


------

Then.... after that screen goes by (with or without errors) it starts on the users, gets two done, and stalls on the 3rd.
No errors, just stops.

Open to ideas here...

Classic has been running here, for almost a decade now... (literally, it's so old, that it was shareware when I paid for it)



But, it's running just fine, with no errors.
I can access the stalled user, through the CP.

Thanks!

The permission on the image folder will need to stay fully writeable if you want to be able to upload new graemlins/icons/etc via the control panel.

As for the user that it's stalling on. It's hard to say for sure. If you open the users file in the members directory with an editor is there anything out of the ordinary in it? When you say it stalls does it stop immediately or just sit there for awhile.

It could be that it's encountering an error but PHP isn't configured to show errors to the browser. You might check you php configuration and see if display_errors is turned off.

It stops on the user, and says "Done" at the bottom of the browser. It's been sitting like that since my original post, and nothing has changed.

I turned on display errors just now, with no change.
(unless I need an IISReset to get it to reload the .ini? do I?)

The user loads up just fine... and I don't see anything "odd"... they are a very old user, with no recent posts in the last 3 years.
It will sound stupid... but he was a friend, that died, and we didn't have the heart to delete his account.

and, to explain why I think the Classic data is stable... I mean that any rebuild I have ever run, has always run successfully.

at this instant, I am running a complete rebuild & reindex of anything and everything, that classic 672 will let you reindex.

(just in case)

Will dump tables and try again after that.

Oh, and can someone on your end, update the threads 7,1 install docs to reflect the comments so far? (IIS permissions errors, plus images dir permissions)

Thanks!

here's what I get, when I run it again and again...


And while I am typing... is that number in the (#) reflective of a new user number, or anything of the sort?

Given the inactivity level... is there any chance that there is some file it is looking for, in relation to the user, that a programmer assumed would always be there, since version X? (ie: the last 3 years)

You will need to do a restart on IIS when changing any of the php.ini settings. It sure sounds like it's coming across some sort of php error causing it to stop abruptly. You could also check your webserver error logs and see if it's logging any problems.

Yes, I can get the docs updated on the IIS permissions. Thanks for the info.

Have someone who has used IIS write that section, please and thanks.


And... will get back to you later.
Rebuilding user subscritions to forums etc, takes a while, and I don't want to screw that up with an IISReset.

Ok, here's the skinny...



That's after turning on the error messages.

Note, my php is in c:\php and not the php5 it mentions here, but at the same time, I have never installed pear, nor was there mention of needing it?

Thanks!
Andrew

but there is a directory named pear at c:\php\pear with only one file in it...