I see that Discount ASP doesn't care about providing a robust API. There is an old thread from 2011 that has been closed that reports this same problem. Is anyone else interested in a Robust API that: .) can backup any database that you pay for .) automatically compresses the backup using gzip or pkzip .) just works when called from a DASP server without having to chase the current IP address I know I'm interested. I am NOT interested in manually signing in every day to backup my database when I have a perfectly acceptable automated way via my website. Sure it's a discount service, it even says that in the name. But when you're not a customer yet there is plenty of marking material bragging about how great they are, blah blah blah. I'm ready for more than blah blah blah now that I'm a paying customer. Who else is?
On a shared server it isn't really feasible to let any one (or everyone) perform backups of any size any time they'd like to, so we have to limit both the backup size and the frequency to maintain stability and performance of the server. And as you probably read in the other thread, the API and control panel use different methods to do the job, which is why the API has the limitation that the Control Panel doesn't. As for not caring about the API, honestly, you're not completely wrong. It's not that we don't care, but it's pretty clear that our customers don't care. When we introduced the API we expected that we would continue to develop and improve it, but our users didn't really take to it, you might say. As evidenced by only one other complaint about the maximum backup size since the API was introduced seven years ago, and very little interest in its many other functions. If more people used it, we would invest more time into it. But as it stands, it's difficult to justify the development time for a tool that a tiny fraction of our customers use. We don't have a huge development team, so we don't have the luxury of creating things just because they're cool, or might be useful to a small subset of users. We have to focus on the projects that will have the greatest impact on the greatest number of people. That isn't to say that we'll never change the SQL functions of the API. I wouldn't rule it out. But if we do, it's not likely to happen very soon, because there are bigger projects on the table. I know that's not what you want to hear, but I hope it makes sense.
It does make sense ... in a way. You have a huge API but this is the one feature that people like me can really benefit from. As you noted, it is used far too little. It seems to me that make a tweak to a size check is a fairly small change, and only one change. For me, that is the difference between having a fully automated site and not. I load data nightly, download my logs, backup my data base and download the copy to my PC in my office. The PC in my office turns itself on at about 8:30 p.m. every day and does all of this whether I am home or not. It took me quite a while to get here and now that I am, I don't like having to give it up. I understand exactly what you are saying. Please consider making this change. If not, please consider offering a webpage that will make the request to the control panel backup API. Then at least I could still send a request with my credentials and get a backup made in an automated fashion. And still manage the versions using the API. And since only a tiny fraction use this API, you probably won't be swamped by people calling it. I get that too.
From http://discountasp.net/sp_opencontrolpanelinitiative.aspx about 10 second ago. "SQL 2012/2008 R2 Backup API Available DiscountASP.NET expands the Open Control Panel Initiative with an SQL 2012 and SQL 2008 R2 Backup API. Now customers can build their own web, desktop, or mobile applications for SQL backups and backup their SQL data without logging into the Control Panel. " I wonder how the great state of California feels about false advertising? Not that I would want to have to got that far or anything. But it was part of the advertising that lured me in to the company that turned out to be a false promise. Puffing aside, how hard would it REALLY be to just comment out that size check? an hour total?
I imagine that would be very easy to do. But taking the "comment out [the] size check" approach would only open the door to problems that could potentially have a negative effect on performance for everyone using the server. I understand that you are primarily concerned with the particular problem you are trying to solve - that's what we all do - but I would hope that you can understand why we might have to take a broader view of the issue. The only responsible way to make the API improvement you're looking for would be to change the method used by the API, and as I'm sure you can imagine, that is much more involved than commenting out a few lines of code. I know it's an improvement that you want. I get it, and I understand why you're frustrated with the API in its current form. But I don't want to string you along or lead you to believe that it's something that's going to be changed soon. I can't make that promise.
I understand part of what you are saying. Unless there's something new I haven't seen yet, SQL Server has some restrictions about the backup destination. No question that if tons of people were making backups simultaneously it could cause problems. And then whatever you are using to compress it and move it to my site space. Yeah. But ... You also say API usage is low. So the chances of the backup API causing whatever problems you are concerned about seems correspondingly low. If the API is functionally stabilized or obsoleted or whatever other fancy term you want to call "no longer supported" then just say that on the API pages on your site. Crowing about how DiscountASP "expands the Open Control Panel Initiative with an SQL 2012 and SQL 2008 R2 Backup API" without actually doing it makes it look like you're talking out of both sides of your mouth. I appreciate your candor while being disappointed with what I'm hearing. What would it take to get this raised in priority enough to get some traction in 14Q1? 2? 10? 100? other users requesting it? perhaps the rabble can be roused.
Removing limits would (potentially and theoretically) allow a single user to consume enough resources to make everyone else on the server feel it. I say "potentially and theoretically," but it's not really theoretical, it's an unfortunate and unavoidable fact of life on any shared server. So we have to do everything we can to prevent those kinds of problems before they happen. Q1 isn't going to happen, I can say that for sure. I alluded to a big project before, and you'll be seeing the results of that in Q1. Other than that, you've brought it up again, and the people who decide what's going into the pipeline read this, so you've already done a lot to bring the issue to the surface. It won't take 100 people asking. I don't think I've ever seen 100 customers agree on anything.
"I don't think I've ever seen 100 customers agree on anything" Now that is genuinely funny. I can't say I like having to sign in and navigate the clumsy API (7 clicks and too near the dangerous "reset my database" button) but I like the idea of no DB backup even less. Looks like I've screamed as much as I can so thanks for tolerating it with good humor.
accident or stealth change .... I was running through my site for a complete overhaul and was pleasantly surprised to see my backup work today. The .bak file was "UnCompressed: 567,612,928" or 541Mb. As part of my update I refreshed my reference to the API. If it was a change, THANK YOU! If not, I guess I slipped through a hole in the space time continuum. Or maybe it was compressing my DB. Or maybe I'm just barely under some other magic limit and will be posting here again soon.
I haven't heard that a change was made, but I'll let you know. And I hope you post here again regardless.
Start Time: 2014-01-21 17:52:44 End Time: 2014-01-21 17:53:04 UnCompressed: 568,661,504 Compressed: 185,200,574 End Zip: 2014-01-21 17:54:39 568M uncompressed seems to be larger than the previously advertised 500Mb limit. I don't know why this changed but am happy that it did. So for me, the backup seems to take about 20 seconds, the gzip 100 seconds. I'm ecstatic that I can ask my web site to backup its database once a day and put this back in my daily load scripts. I have today's backup on site on the space I pay for and download it tomorrow, just before loading new stuff for the day. Zero touch, 100% automated, as it should be. [Insert comment about a well-oiled machine or equivalent simile here].
