This is a concise post of my past year and a half experience and serious DNN system problems that the Turbo DNN scripts have caused onto a typical fresh very well maintained DNN installation.
I really hope that this post will stop and discourage all users from applying these scripts and even those like me that they have applied they will eventually CANNOT MIGRATE to the LATEST DNN VERSIONS (i.e. 7.4.0 7.4.1) !!!
And after one will post his/her unresolved issued onto dnntracker.atlassian.net and either you will not get any reply from anyone or the known Board moderators / developers of the Community state that your issue is characterized as CNR, you will end up to my dead-end.
I'll first lay out a brief outcome of the problems that I'm facing as a Host user upon a normal & well maintained DNN installation and then for the proof of my sayings all the issues that I posted onto dnntracker.atlassian.net and see the replies of the fore mentioned Board moderators / developers, for the past 1 7 ½ year !
PROBLEMS (please do not query or try to troubleshoot reasons of the cases – just read on) – I listed them according to severity hierarchy:
Cannot upgrade DNN Community Platform from 7.3.4 neither to 7.4.0 not to the latest 7.4.1
Cannot add/remove child and/or parent portals.
Cannot move page properly by Page Management to a different hierarchy
Cannot rename Page Settings of a no. of pages (not all but an non logical set of pages)
Journal Module and all as result the Community / Groups / Members expected operation
Now please read my posting on DNN Community as a global result of TurboDNN unique benefits:
http://www.dnnsoftware.com/forums/for...
(and, Sebastian do not consider this link posting to be advertizingly promotional J, well is not.
At the same time study the formality, detailability and carefulness of the writing of my posted issues, then read Mr. Leopold's replies onto mine and judge for yourselves !
System Issues upon the DNN installation INFECTED by TurboDNN scripts:
First
Journal Module Correct Operation Critical Error:
https://dnntracker.atlassian.net/brow...
Title: DotNetNuke.Services.Social.Messaging.Scheduler.CoreMessagingScheduler, DotNetNuke Critical Error
Note Moderator's comment:
"...
that's a stored procedure which is expected to exist - the only reason it would not is if you had a failed upgrade (or if you used a 3rd party sql script which dropped it).
..."
Second (serious issue):
https://dnntracker.atlassian.net/brow...
Title: Site Management is currently unavailable when deleting Parent Portal
Note Moderator's comment:
"...
we already had a fixed scope for 7.4.0 so were not considering any other issues for that release - we will be reviewing issues for 7.4.1 soon.
..."
"...
I've moved this into 7.4.1 so it will be looked at into the next cycle - we'll first have to recreate it (sometimes issues are localized to people's installs as changes have happened via 3rd party modules/scripts), before deciding what actions to do. We don't provide builds/scripts as we don't have the resources to support individual users - however if a fix is needed, when the fix is done it will be associated with the issue so you can see the checkings, and sometimes it's possible to replicate that in your environment
..."
Mr Leupold is trying again to promote & persuade his TurboDNN scripts:
Sebastian Leupold added a comment - 02/Feb/15 5:31 PM
you may check out my scripts at http://dnnscript.codeplex.com.
IN TurboDNN.sql, there should be a version of procedure DeletePortal, which should solve this issue as well.
My reply to Sebastian:
"...
Sebastian, I am not using and of your scripts cause they created me serious issues before and I have reported them.
I do follow Cathal's recommendations not to incorporated any 3rd party scripts since they are unsupported by the Community and your support is not adequate.
You may search and find issues that I have raised over the last year in Turbo DNN's codeplex page.
You could not find solutions onto them.
So please do not recommend these scripts.
...."
Sebastian's "naive" reply:"
"....
InteliBrain,
I am well Aware of the risks associated or incorporated with my scripts and always try to provide best Support possible for any open source Software.
I didn't suggest applying the full script, just the single stored procedure, which fixes the core issue o not deleting all site data.
But it is just a suggestion, but feel free to wait until someone fixes the issue.
..."
Just read & judge the series of Q&A's & read his final reply:
".............................................................
Sebastian Leupold added a comment - 11/Apr/15 11:09 AM
INTELIBRAIN,
we added several foreign keys to permission tables in DNN 7.2.1 (if I remember correctly). Those include a cascade delete, but for technical reasons, this is not possible to roles table, therefore roles (and a couple other objects) need to be deleted explicitly in delete portal sproc.
PanosM InteliBrain added a comment - 16/Apr/15 2:16 AM - edited
Sebastian, You do not answer my point.
I stated clearly what in my professional opinion should have done, in these critical scripts that you have written, but instead you answer in a non-relative matter.
Plus you have been answered by both Cathal and Joe BrinkMan upon the use of these scripts.
Sebastian Leupold added a comment - 16/Apr/15 2:26 AM
InteliBrain,
I try my best to provide value to the community and there are a number of members, who appreciate it. There are clear statements about the character of turbo scripts, and so far I was able to assist all users and solve their issues.
Of course, Cathal and Joe don't like the scripts, but I got tired and don't have the time to discuss every line of SQL code to get integrated into DNN Core Framework - for those, who need a better database for their site, I provide the option by using my scripts.
PanosM InteliBrain added a comment - 04/May/15 11:24 PM
I understand and respect what you claim.
I should mention to you that my problems have not been solved at that time, by you, besides my efforts and reports.
What you should provide though is:
1. Full uninstallation of TurboDNN scripts once they have applied and possibly cause any issue.
2. Comprehensive Possibility to revert back to the "untouched" DNN DB & System (possibly) with scripts (nee to mention that the TurboUnSchemaxxx.sql script does not do that job.
Can you provide such scripts?
Sebastian Leupold added a comment - 05/May/15 2:26 AM - edited
no, there are too many issues in DNN core database, for which I won't waste time to re-introduce.
If you install TurboDNN, I will do my best to iron out any issue, my users experience.
PanosM InteliBrain added a comment - 06/May/15 11:53 PM
Are you providing such scripts, as we speak now?
1. Full uninstallation of TurboDNN scripts once they have applied and possibly cause any issue.
2. Comprehensive Possibility to revert back to the "untouched" DNN DB & System (possibly) with scripts (nee to mention that the TurboUnSchemaxxx.sql script does not do that job.
Sebastian Leupold added a comment - 06/May/15 11:58 PM
short answer: no
....................................................................................."
AND THE FINAL MODERATOR's judgment and dead-lined, for me, situation:
"...
note: this issue is closed as it was caused by the changes in database structure from an unsupported 3rd person utility (turbosql) - we can’t support any database that is changed - nor can be accept files/database from DNN installs that have ran unsupported database changes.
...."
"...
Closed per ..... comments
...."
<..... see on the next issues, how many times the issue is been referenced after my case has been identified that my installation is totally supportless and thus been referenced onto !! Just memorize the issue #6317 ....>
Third (more serious issue):
https://dnntracker.atlassian.net/brow...
Title: Unable to delete Parent Portal
Note Moderator's comment:
"...
this appears to be a duplicate of https://dnntracker.atlassian.net/brow..., which has been closed as the database structure was changed by 3rd party script. I’m going to close this as a cannot reproduce.
..."
".....
note: this issue is closed as it was caused by the changes in database structure from an unsupported 3rd person utility (turbosql) - we can’t support any database that is changed - nor can be accept files/database from DNN installs that have ran unsupported database changes.
If you have an issue with Sebastian's script I suggest you raise it in his issue tracker -http://dnnscript.codeplex.com/
..."
AND THE FINAL MODERATOR's judgment and dead-lined, for me, situation:
"...
Closed per ..... comments
...."
DEAD END !
Fourth: (the most serious one)
https://dnntracker.atlassian.net/brow...
Title: DNN 7.4.0 Upgrade Reports Error at 25% of Installation
Note Moderator's comment:
"....
I believe this is caused by users who have ran turbosql scripts - please note, running 3rd party scripts against platform database objects means you are running an unsupported fork
...."
<......................... go through the whole history of posts - replies if u have the patience .........>
Note Moderator's comment:
"....
I’m going to close this ticket as we can’t support sites that have applied 3rd party scripts
...."
Note Moderator's comment:
"....
site had applied turbodnn so we cannot support.
...."
Sebastian's helpless replies:
btw: I will elaborate on this in my database session at DNN-Connect conference (http://dnn-connect.org/2015)
I encourage you read the following discussion.
Hope you will find it funny :) (not for me thought !)
"........................
InteliBrain added a comment - 07/May/15 12:23 AM
You will make me now to re-construct the whole site from scratch?
Why don't you STATE that in the most clear way to your codeplex page as a disclaimer?
I've spent 4 months doing that site !
You are carrying away all the people that applying these scripts and then the whole DNN community is not supporting any upgrade bug that these scripts are producing.
Sebastian Leupold added a comment - 07/May/15 12:27 AM
no one is forced to redo a site, there are a number of happy users of the scripts.
but you have to accept that you need to stick to it, once you applied it - and you will face less bugs and better Performance, than using just DNN Default scripts.
InteliBrain added a comment - 07/May/15 12:46 AM
I had serious issues with those scripts and you could not give the appropriate support that I was expecting, issues that troubled me with no resolution for a lot of months and finally kept me stuck on a older version, this is why I'm feeling that I'm forced to proceed into such drastic action.
Unless I will revert back to a clean DNN installation a significant number of issues that I'm facing will meet Cathal's replies that they cannot support installations where 3rd party scripts have been applied onto.
So, this is dreadful !
So I'm weighing the two supports and I'm selecting the DNN Community's one that is much bigger and strong.
Sebastian Leupold added a comment - 07/May/15 1:03 AM
Panos,
of course it is your own decision, how to implement your DNN and its database.
You are the only one of all users of TurboDNN with a bad experience (though there are other users with issues, I was able to solve all of them quickly - besides Support for AzureSQL, due to compatibility limitations)
..."
The last Sebastian's reply I will leave it onto you to judge !
NOW:
############################################################################
See and judge what a DNN expert technical engineer from a well known DNN Hoster stated about the result of the Turbo DNN scripts:
Panagiotis,
The TurboDNN scripts make very heavy database modifications and completely changes the way that DNN runs, which is why it is considered to be a branch of DNN. While they can be great for the speed of your site, we don't recommend running them, as it does change a lot of core tables in DNN.
To migrate an existing DNN site to a new one can be a bit tricky, but here are the steps:
You could either:
1) Set up a new installation of DNN and manually recreate all content
or
2) you could attempt to use DNN's portal export feature:
Instructions for that is here: http://www.ventrian.com/blog/exportin...
Exporting/Importing content can be un-reliable, however. Only modules that support the ability to be exported will be exported, and there really isn't a way to tell which modules do or don't support it. In order to import the content and modules, the installation that the content is imported on needs to have all the same modules (same versions as the exported content) and skins, otherwise it won't restore correctly.
We recommend doing the first way, as the latter seems to be rather un-reliable, but you are certainly welcome to give that a shot.
Please let me know if you have any further questions with this ticket, or if something needs to be addressed further.
############################################################################
I stressed to Sebastian before that he should sit down and write a thorough long informative d i s c l a i m e r on the effects of his turbodnn scripts onto a DNN installation and its database!
Plus like all applications he ought to have provided a full uninstallation procedure not matter how hard that seems to be implemented - not a one way down to the cliff - with no way up !
He holds the responsibility of the effects and all this huge amount of time trying to debug and confront with all the issues arising after the appliance of his scripts of promoting these scripts and replying onto so many DNN Community users posts - have you noticed?
I hope I have contributed to the Community so as much as possible DNN users will not apply these catastrophic scripts and will not end up in my situation.