Import MySQL-Database failed after upgrade to Plesk 11.5 or latest update

[PedroN]

I really can not believe it. Until a group of people do not complain parallels team does nothing. I think this link you provided: http://forum.parallels.com/showthread.php?106115
Is rubish, all that information that you are asking it was very clearly specified by the first person who posted the thread.
Product: parallels (facepalm)
version: "Since we upgraded to Plesk 11.5 or (I'm not shure) the last Update 12"
operating system: WHAAAAATTT, seriously, I do not know, common sense please, we are asking for a solution in the windows plesk forum.
PROBLEM DESCRIPTION: "If the user open phpMyAdmin for import and select the database and click on Ok, phpMyAdmin does nothing."
STEPS TO REPRODUCE: "Since we upgraded to Plesk 11.5"
ACTUAL RESULT: "If the user open phpMyAdmin for import and select the database and click on Ok, phpMyAdmin does nothing."
EXPECTED RESULT :WWHHHHHHHAAAAAAAAAAATTTTTTT, mmm, I am silly. expected result, common senseee. I want to import a database as simple as that
ANY ADDITIONAL INFORMATION: mmmmmmm, nothiiiiiiiiiiiiiiiiiiinggg, it is very simple, we can not import a database and that´s it.

Like you see all information was provided by the first person. Please I though that you were people and not bots without a brain, think a little bit, most things were common sense,and until a group of people does not complain the company or team support as always do nothing.

 

[IgorG]

It is pity that you can not understand that not all problems that you post here can be reproduced by us for different reasons and we can not help you immediately. Therefore, we request your assistance in such cases. If this normal and usual cooperation between community and us makes you laugh, then I do not think it would be productive for all of us.
A lot of people before you have used this workflow and get professional help from us. You can continue to sneer and laugh more.
Thank you for understanding.

 

[Faris Raouf]

Product: parallels (facepalm)

You cheered up my day. hehehe

But seriously folks, we have both a language barrier problem and an engineering-v-user problem here.

For those people experiencing the problem:
The issue needs to be resolved as soon as possible. It is an annoying issue. In order to achieve this, certain procedures need to be followed.
Yes, they are annoying procedures, and yes, they seem pointless sometimes, but they do need to be followed. Specifically, the Parallels engineers need specific data and ideally as many clues as possible in order in order to narrow down the cause.

For a product as complex as Plesk, an issue that seems obvious and easy to identify to us users may in fact be really difficult to reproduce by those people who are tasked to investigate. What's more, in order to get the issue investigated and fixed as quickly as possible, we need to give as much information as possible and in a certain format to allow for quick and easy transcription.

And that means we users have to go through the process of making a post based on the information requested on the dreaded http://forum.parallels.com/showthread.php?106115

And we need to go through the appropriate logs to see if there are any clues as to the cause, and include those clues in our reports. Even a lack of anything in a log can be a clue to something.

This information can then be copied and pasted by Igor and his team into the appropriate Parallels tracking system, where the engineering guys can look at it and ideally more easily reproduce it and issue a fix for it.


Many of you support your own users, right? You know how it is. Things are not always as obvious as they might seem to users. Let me give you a silly but real example: The other day I had a call from a customer whose email was being rejected by some mailserver or other. They wanted me to fix it instantly. I asked them to tell me what it said in the error message or bounce message they were receiving, as this would allow me to identify the issue easily and quickly. Unfortunately they were calling from work, and the issue was happening on their home PC so they could not do so. I explained that there wasn't much I could do without the necessary information, and they started getting really annoyed. So, with a silent sigh to myself, I told them I'd see what I could do and spent quite some time going through the email logs on the server, trying to find something to explain their problem. I failed to find anything.

The next day the customer called again, very annoyed at me for not having magically fixed the problem for them. But they did have the bounce message for me this time. And guess what? They weren't using our server for sending their emails, they were using their ISP's SMTP server, and from the bounce message I was instantly able to see that their ISP's SMTP server had been blacklisted, hence the delivery problem. So I'd spent ages chasing my tail looking in the wrong place for the problem. If the customer had given me the information I needed in the first place, I would have been able to help them much more quickly.

Yes, yes, I know, this example isn't the same thing as this issue you are having right now. What I'm trying to explain is that to us users, although we may see an obvious problem and an obvious source, to an engineer who wants to fix the problem for us it might not be quite so straightforward, at least not in every single case. Heck, I've had issues with software that were caused by a Windows update (desktop) that happened to get installed on the same day as I updated the package I was having problems with. I'm not trying to say this that the latest update is the cause here -- I'm just giving an example, poor as it may be.

So we have to go through the pain of http://forum.parallels.com/showthread.php?106115 giving specific version info, problem info and so on, and also we have to go through the annoyance of finding and looking through some logs. It takes us time to do it, but it speeds up the process of getting the result we want -- getting the problem fixed.

Whew, sorry for boring you all to death with this post. I just don't like seeing customers getting annoyed like this - I can feel the frustration but I can also see the other side of the coin too. So let's get some of those full reports done please, so Igor can copy and paste. And the more full reports, the more ammunition we have for bumping the fix to the top of the queue, I would imagine.

 

[IgorG]

Problem has been fixed in MU#13 - http://kb.parallels.com/116874

 

[John-M]

Thanks, Igor.

I look forward to using the mySQL import when I next need it.

It's good to see that common sense has prevailed, and I hope this becomes the "norm" in future. Please remember that we pay for the software to use it, and many of us are not experts in PHP. We therefore require proper support, without having barriers put in our way just for the sake of it. I'm sure that Parallels are as interested as we are in making sure the software works properly. After all, there are other very good products out there - although, I must admit, Parallels software is generally very dependable.

Regards, John

 

[chili1001]

I have installed the patch # 13 and can confirm that the import works again in phpMyAdmin.

Regards,
Matthias

 

[InderS]

try updating plesk to latest version with microupdates. That will fix it.