I can't beleive I paid for this
CodeDreamer68
Posts: 5
I am extremely frustrated right now because I've paid for a utility that is supposed to save me time, but is actually wasting my time. That angers me greatly.
Frankly, at this point I seriously doubt that I will recommend this product for upgrade within our corporation. You can also expect me to express my complete disatisfaction with Red Gate SQL Packager on my blog as well.
You people have had plenty of time to fix the problems with your software, it was released in 2008, no?
For the record, I'll state the top 3 problems I have with your software (not that you'll do anything about it, because I've complained before, a year ago and you obviously haven't fixed it yet)
First, using the wizard, when I uncheck boxes for objects in my database, the packager seems to completely ignore my un-selections and scripts them anyway. So that means I have to go through the script, that your software generates, line-by-line and remove all the objects that I didn't want scripted.
This means I can't build an executable installer package, because your software dosn't allow you to edit the script manually, prior to creating said executable package.
Second, the script also seems to create db objects in the incorrect order, thereby causing catastrophic errors that cease the execution of the script and rollback the transaction. For example: one of my my databases has FK constraints that your tool puts BEFORE the place in the script where it actually creates the tables to which they should be attached. I have to cut and paste the sections where the tables are created so they get created PRIOR to the objects such as FK constraints, defaults, and descriptions.
Thirdly, your product does a lousy job of handling FullText catalogs. The script completely crashes when it creates stored procedures that contain any fulltext references, because those tables that were created by the script, did not get their full text indexes created yet. For some idiotic reason you decided to put all the lines of script that create the full text catalogs at the BOTTOM of the script. WTF are you thinking?
All these serious problems make me want to ask for my money back.
Your product is completely useless and has no value. If I wanted to just have some tool automatically script my database, so I would then have to go through it line-by-line, and re-script it manually... then I would have just used Visual Studio's database deployment feature.
Explain to me why anyone would buy this POS?
Frankly, at this point I seriously doubt that I will recommend this product for upgrade within our corporation. You can also expect me to express my complete disatisfaction with Red Gate SQL Packager on my blog as well.
You people have had plenty of time to fix the problems with your software, it was released in 2008, no?
For the record, I'll state the top 3 problems I have with your software (not that you'll do anything about it, because I've complained before, a year ago and you obviously haven't fixed it yet)
First, using the wizard, when I uncheck boxes for objects in my database, the packager seems to completely ignore my un-selections and scripts them anyway. So that means I have to go through the script, that your software generates, line-by-line and remove all the objects that I didn't want scripted.
This means I can't build an executable installer package, because your software dosn't allow you to edit the script manually, prior to creating said executable package.
Second, the script also seems to create db objects in the incorrect order, thereby causing catastrophic errors that cease the execution of the script and rollback the transaction. For example: one of my my databases has FK constraints that your tool puts BEFORE the place in the script where it actually creates the tables to which they should be attached. I have to cut and paste the sections where the tables are created so they get created PRIOR to the objects such as FK constraints, defaults, and descriptions.
Thirdly, your product does a lousy job of handling FullText catalogs. The script completely crashes when it creates stored procedures that contain any fulltext references, because those tables that were created by the script, did not get their full text indexes created yet. For some idiotic reason you decided to put all the lines of script that create the full text catalogs at the BOTTOM of the script. WTF are you thinking?
All these serious problems make me want to ask for my money back.
Your product is completely useless and has no value. If I wanted to just have some tool automatically script my database, so I would then have to go through it line-by-line, and re-script it manually... then I would have just used Visual Studio's database deployment feature.
Explain to me why anyone would buy this POS?
Comments
I believe you have found the private release version now, so hopfully this should resolve your first issue. (Tools > Options > schema options > [uncheck] include dependencies)
When you try the patch version, can you see if using the updated SQL Comapre & SQL Data compare engines also resolves your script order issue?
With regards to the FullText catalogs, unfortunatly this is actually quite difficult to resolve.
Changes to the FULLTEXT Catalog or Indexes cannot be placed into a transaction and therefore have to be scripted somewhere outside of the transaction. If we put the full text stuff first and then there was a problem with the subsequent transaction, then the database would be left in an inconsistent state. We feel that it's better to create a script that fails and rollsback, rather then damages the database.
The usual workaround to this problem (with SQL Compare) is to compare the two data sources, synchronize the FULLTEXT Catalog first on it own, then refresh the comparison and synchronize the remaining database objects. With SQL Packager, you could use the same approach, but save a sync script for each, then join them together and use the 'package script' feature of SQL Packager 6.
I hope this is helpful.
My needs are simple.
#1 I need to create a package that my end users can execute to install my database. I can do this manually myself, without your software.
#2 I want to save myself time. Instead of having to manually create an installer package myself, from scripts generated with either Visual Studio data tools, SQL Server Management Studio, or CodeSmith, I need a tool that is smart enough to do it for me. (That's what I was led to believe SQL Packager is)
Your product, even after your suggestions and excuses, still does not meet my needs or the needs of my corporation. As such, I cannot recommend upgrade again.
Where is the version that works, and why haven't the fixes been rolled into the version you offer to download?
I need the working version as quickly as possible; please respond promptly.
EDIT:
I just saw the sticky thread with the patch, going to try it out now.
On a side note, you may be waiting for more testing before rolling out this patch, but not having a working product has cost my company an extra couple of hours of productivity due to me wasting time having to first find out the product was shipped buggy and then having to research where to find the patch. The LEAST you could do is include the information in the receipt of purchase, if you aren't willing to provide a better working copy in your trial showcase.
Perhaps it was my fault in assuming the product would work as purported to do, considering how strong some of your other products are. Next time I will fully test any product of yours before making a recommendation on purchase.
If the transactional features (and in my case it's the only way your software is useful) are disabled you shouldn't have an issue placing the full text catalog script in a better location suited to the objects dependent on them. Just a thought for your next private patch.
I am pretty horrified that our first day as a user, I have immediatly run into this really fundamental issue that doesnt seem to have been addressed, even with the patch.
Just to be clear, when I deselect User objects (because they wont exist on a customers server), they are still included in the script.
As a new purchaser of the full ToolBelt, I will not sit around until my distance selling and other rights have expired before obtaining a refund.