Salakhetdinov Shamil
mcp2004 at mail.ru
Thu Nov 6 15:29:09 CST 2014
Hi Arthur -- Azure SQL Database(s) of 'Premium/P3' Service Tier/Performance Layer could be as large as 500 GB each ( http://msdn.microsoft.com/library/azure/dn741336.aspx ). And we're talking here about the max size of the default Azure SQL database instance created for Office 365 MS Access application ( http://www.devhut.net/2014/01/13/how-to-hybridize-your-ms-access-database-in-office-365-azure-database/ ). There is no need to have Azure SQL account to handle this database via MS Access Office 365 application and/or desktop MS Access application linked to that Azure SQL database using ODBC DSN connection. And there is no limitation(?) of the quantity of such applications per Office 365 account. If you'll find the default size of Azure SQL Database serving as BE for MS Access Office 365 app isn't large enough you can migrate/upsize it to a full scale Azure SQL Database. But then you'll first have to create an Azure SQL account with 'pay-as-you-go' subscription type. "Modularized MS Access" apps - yes, we have been using them here since MS Access 97. Thank you. -- Shamil Thu, 6 Nov 2014 13:18:08 -0500 from Arthur Fuller <fuller.artful at gmail.com>: >I'm frankly a bit stunned by your numbers. Are you talking about the FE or >the BE? Several Access FEs I've written address MS-SQL or MySQL BEs over >50GB in size, running on clusters. In that situation, I bind forms to >stored procedures and find performance acceptable. Mind you, I learned a >significant lesson long ago, which I call the Sally Rand Principle -- named >for a famous American stripper, whose motto was, "Show them just a little >more at a time, to pique their interest." More concrete; I would for >example present a list of sales orders, bound to an SP that selected orders >in the past 30 days, but with buttons on the form's header to switch to >60/90/120 days. All that required was simple code to pass a different >parameter to the SP. Dead simple, really; it gave the users everything they >wanted most of the time, and everything available, in chunks, depending on >the ambition of their question at the moment. > >I also learned, relatively early on into these adventures, and decided way >back when to separate reports into a second app that did nothing but >report. And finally, I learned an approach from Jim Dettman that I took >very seriously. Before I met him, I had the bad habit of rolling everything >into a single massive Access app. But Jim presented another approach >completely. and his wisdom inspired me to rethink my whole approach to >Access development. Instead of one massive app that did everything but the >dishes, Jim had about 30 apps that each did exactly one thing, and their >AutoExec code fired a procedure and as soon as it was complete, exited. I >had never even considered that approach before encountering Jim's apps. > >The huge gain in Jim's approach is the ability to schedule apps using >Windows Scheduler. Some reports need to run once a day at a particular >time; others are weekly, and others month-end; and a few others quarterly >or annually. The result is that the user sees a lot of shortuts but can >drag them into meaningful groups based on frequency of use and act >accordingly -- or, even better, just schedule these tiny programs and >forget about it. > >I thank Jim for that profound insight. > >Arthur > >-- >AccessD mailing list >AccessD at databaseadvisors.com >http://databaseadvisors.com/mailman/listinfo/accessd >Website: http://www.databaseadvisors.com