Products

Solutions

Resources

Partners

Community

Blog

About

QA

Ideas Test

New Community Website

Ordinarily, you'd be at the right spot, but we've recently launched a brand new community website... For the community, by the community.

Yay... Take Me to the Community!

Welcome to the DNN Community Forums, your preferred source of online community support for all things related to DNN.
In order to participate you must be a registered DNNizen

HomeHomeUsing DNN Platf...Using DNN Platf...Administration ...Administration ...Turbo DNN scripts results onto a DNN installation - UnSupported by DNN CommunityTurbo DNN scripts results onto a DNN installation - UnSupported by DNN Community
Previous
 
Next
New Post
6/4/2015 10:13 PM
 

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.


Panagiotis Mylonas Managing Director InteliBrain http://InteliBrain.gr
 
New Post
6/5/2015 5:08 AM
 

As creator of the Turbo DNN scripts let me explain some of the Background:

Background

For those, who are not aware, TurboDNN is a set of SQL scripts to improve performance and stability of the DotNetNuke database. The background of this project was a client site with 180 000 users, which had significant issues and some parts like site settings became inaccessible to run after an upgrade to DNN 7. Being a database developer myself for more than 20 years now, when inspecting the issue, I noticed the cause in an inefficient stored procedure and the same time found a couple of others. I started to create a script to fix them all and logged more than 100 issues in JIRA, more than half of them were integrated with DNN core (unfortunately not all the most effective ones). I further worked on improving the database, not just optimizing for performance, but also fixing a number of bugs, I noticed during my work. This is an ongoing effort now for nearly two years.

Technical Overview

Most of the changes started with optimized stored procedures to retrieve data more efficiently. Those stored procedures often use views and functions, which I optimized as well. The most relevant database objects for performance are indexes. I reviewed and optimized indexes for nearly all tables to make sure it suits the need of DNN best. I also recreate all foreign keys between core tables to make sure, it implements referential integrity as good as possible. I started adding check constraints to ensure better data quality in the tables. Besides indexes and constraints, there are (currently) no changes at the tables itself (wait, I added a single calculated column to user profile). There are few data changes, mainly removing orphaned records or replace invalid data with Null to be able to implement foreign keys. (Unfortunately, DNN has the bad habit of storing -1 instead of Null in many columns to indicate a Null value, but there are some objects like portals, users and groups, which use negative values for special cases, which doesn't makes this easier). All these changes are contained in a large script called TurboDNN741.sql (the number increases with the latest DNN version supported).

Besides, there is TurboSchema741.sql, which adds Schemabinding to Functions and Views as well as Indexes to the views, which makes them to perform like a single table. As Schemabinding prevents underlying table structure from being modified, there is a TurboUnSchema741.sql, which has to be executed prior to applying DNN core database modifications, which are usually part of DNN upgrade scripts.

Turbo scripts use a special mechanism to provide the correct version of  each procedure/function/view for each DNN version, therefore it needs to be re-applied after each upgrade. Also, DNN upgrades might overwrite Turbo objects with its (less performing) pendants, which even might result in procedures not being executed correctly.

Effect

You should notice a performance increase immediately after applying Turbo scripts and restarting DNN. Of course, this just applies to database actions, once data is cached in DNN, there will be no difference, and of course it cannot improve processing JavaScript on the client. Measurements from a user on a small site resulted in 20% decrease of total page load time, this effect will be more noticeable on large DNN installations with many users, folders and portals.

Support

Turbo scripts are created as an open source add-on project, living on CodePlex. I use it on many of my clients and am contiuously working to improve and update it to support latest version, this is also a promise to all uses, who rely on it. Turbo scripts are released "as is" without any guarantee, but of course I try to support all users as good as I can and most of the reported issues are fixed in new versions of the script within a few days or even hours. Due to the nature of the scripts, they should heal issues from previous versions automatically. With individual issues, I provide best support using forums (preferred) or direct messages, however I cannot fulfil requests like "I send you my database, you fix the issue" for free or other requests, which are out of scope. And, last but not least, my support heavily relies on the co-operation of the requester.

In the concrete case mentioned above, the poster stopped cooperating and tried to restore a previous backup, which seem to have (partly) failed and resulted in an inconsistent database, which cannot be fixed by a script, but only by a proper restore (which would remove meanwhile added content) or a manual merge.

If you are having any questions, I'll be happy to answer (non-offending tune preferred).


Cheers from Germany,
Sebastian Leupold

dnnWerk - The DotNetNuke Experts   German Spoken DotNetNuke User Group

Speed up your DNN Websites with TurboDNN
 
New Post
6/24/2015 12:59 PM
 
Hi Sebastian

Thanks for creating Turbo Script. We have tried installing it but it is not going so well for us :-)
We have DNN 7.4 and are using Catalook shopping cart.

When we tried to install it, it creates a "System.Data.SqlClient.SqlException (0x80131904): Error converting data type nvarchar to float.
The statement has been terminated. " issue. We have logged it on CodePlex as an issue here: https://dnnscript.codeplex.com/workit...

Do you have any advice on this please ?

Thanks, Ted
 
New Post
6/24/2015 6:03 PM
 
Ted, I replied to the issue, as I am having additional question. The problem is most likely in the data - Turbo is adding a calculated field to UserProfile, which contains an integer representation of the content, if it can be converted to a number, in order to be indexed and efficiently being joined with other tables like Lists. There seem to be a value which is identified as Number, but cannot be converted into a number.

Cheers from Germany,
Sebastian Leupold

dnnWerk - The DotNetNuke Experts   German Spoken DotNetNuke User Group

Speed up your DNN Websites with TurboDNN
 
Previous
 
Next
HomeHomeUsing DNN Platf...Using DNN Platf...Administration ...Administration ...Turbo DNN scripts results onto a DNN installation - UnSupported by DNN CommunityTurbo DNN scripts results onto a DNN installation - UnSupported by DNN Community


These Forums are dedicated to discussion of DNN Platform and Evoq Solutions.

For the benefit of the community and to protect the integrity of the ecosystem, please observe the following posting guidelines:

  1. No Advertising. This includes promotion of commercial and non-commercial products or services which are not directly related to DNN.
  2. No vendor trolling / poaching. If someone posts about a vendor issue, allow the vendor or other customers to respond. Any post that looks like trolling / poaching will be removed.
  3. Discussion or promotion of DNN Platform product releases under a different brand name are strictly prohibited.
  4. No Flaming or Trolling.
  5. No Profanity, Racism, or Prejudice.
  6. Site Moderators have the final word on approving / removing a thread or post or comment.
  7. English language posting only, please.
What is Liquid Content?
Find Out
What is Liquid Content?
Find Out
What is Liquid Content?
Find Out