I have published some Tableau extracts which are pulled from Microsoft SQL server. The extracts are very large, and are scheduled for early in the morning only once a month. I would like to prevent anyone from accidentally refreshing these, even Site Administrator.
When I publish the Data Source, it says I need to embed the authorization for refreshing on a schedule. However now when I've embedded the credentials, any site admins can still select refresh. Is there any way to take that option away, and only allow Server Admins to manually refresh the data?
Related
Say I have 10K users for my app and I want to switch to my own custom server for backend. I have seen the Parse export functionality but I don't get how it can help me in this situation.
I mean even if I export all data and make updates to app so that it makes calls to my new custom server, still, it will take months for all my users to use updated version of app(many users don't update immediately, my last update on fb was year ago).
Also, during this transition half of my users would be having their
data on my custom server and other half(those who haven't updated)
would be using parse server, so for queries that require all data in one place this becomes an issue (I could solve this via replication but imagine how slow it would be in realtime to push the data to both - my server and parse.com).
Has anyone thought about this ?
What you could do is when you release a new version of your app, when a user logs in and they are on parse, migrate their data at that point to the new server and from that point on that user uses the custom server. That way users move to the new server as they upgrade, I always have a flag that is fetched from my server to force the user to upgrade if is needed. Hope that helps.
Copying data over to your new backend periodically until you have finalize your mobile client code and then allow the user to update their app on the App Store or Google Play Store would provide the switch over. Doing that elegantly would be dependent on the type of app and user base you have for the app. I wrote up a part 1 of a blog on these considerations for migrating over from Parse to Couchbase Mobile stack and the reasons why to consider the stack.
If you can already attach a new system in place to have new data in two places (Parse and customer backend) then the copy and merge in the future might be easier to handle but this is case by case. Then when on mobile app update, you can depreciate the server. Or push data to have local store for those users who will be on older versions since Parse will eventually stop working. Any new experiences will require update to the new App version.
It seems to me as a wise idea to test run my workflow on a local server before deploying in at the customer's. To be entirely sure, I'd like to copy all the data from their DB to my test organization (I have full access rights). The problem is that I can't see any straightforward way to export the whole shabang to a XML Spreadsheet.
What's the best way to export/import everything from/to a DB? The source and the target servers are not the same.
Of course I've got the option of backing up the clients DB and restore it, would the brown stuff hit the fan, but it'll far more professional if I won't have to.
The client's DB is in the cloud, which makes me suspect that perhaps I won't be able to access it at all and as far I can see, there's no way to back-up the data there. Am I missing it or is it that bad?
I fully agree that would be sensible. Usually we have a number development and test servers for all our work, generally we do not exactly mirror the data in the client database however.
We create a representative sample of data in our dev servers and then just move across the Crm solution for deployment.
As far as I know there is not straight forward way to get all the data, if you really want to do this I would suggest taking a back up of their database and importing to yours.
(As a side note, not all clients are happy for copies of their database - especially if its a live system - to be taken off site. Personally if it is a live database I wouldn’t put that risk on yourself, if the data gets lost or leaked you might suffer the consequences).
James raises good points about the business aspects of your request, however to get hold of the record-level data there are few options. The easiest by far is a wholesale export and import of the underlying SQL database. (For the record, the alternative is to do a data migration from live into a different db but this is no small task so I won't even entertain that any further here).
You mention that the client is using CRM Online ("...client's DB is in the cloud..."). You can raise a (free) support request with CRM Online Support who will provide you with a copy of the YourOrg_MSCRM database which can then be reimported into an on-premise deployment.
If you wish to simply have a test instance that has a copy of the Microsoft CRM Online organization, Microsoft does provide a means to do that. Depending on how many professional user licenses that the customer has, this may be free, but could be an extra cost and both instances would count against the storage limit for Microsoft CRM Online. You can see full details here - https://community.dynamics.com/crm/b/crmteamblog/archive/2014/03/20/introducing-sandbox-instances-in-crm-online.aspx . You can see steps on how to setup a sandbox instance here - https://technet.microsoft.com/en-us/library/dn467371.aspx "Add an instance to your subscription". This is something that I have used with one of our Microsoft CRM customers as it was a very good way to help validate the Scribe Online migration and customization changes we were making before moving those into production. The nice thing about doing it this way is that everything is still contained in the same Office 365 tenant and you can limit which users have access to the Sandbox organization, which is important for customers in knowing that their data is safe and not on some unknown server or machine.
I have a business LS web application which I update from time to time.
I do the update by simply using the deploy wizard and everything is working great.
My problem is handling all my users that opened my system in their IE and left it open through my deploy process.
Since they have the old web application is opened on their browsers, and I have deployed the new version to the server, I can see errors occuring in certain situations.
Is there a way to make sure all users with the application opened will be forced to refresh the web application page? Maybe remotely disconnect all currently connected users?
There is no built in way of doing this. You will need to write a custom solution. Someone in the MSDN Forums has written a class to do this for OOB apps.
You should be able to reuse the timer part of that class. I'm not sure if the UpdateAvailable method will work for Web-based applications or not. You'll have to experiment with that.
Alternatively, you can create a custom notification system. Insert a message to your users into a table in your database from the administrator account. Have a timer on the user account check the table every so often. If it finds a new message, display a notification to the user.
Then you can use either an HTTP Response Header or an ASP method to log the users out as described in this Microsoft Support article.
I have implemented Continuous Integration using TFS Version Control and TFS Build 2010. The compiled website project gets dropped in a shared folder with a version number.
Now I have a very basic question and may be a stupid question. When we normally deploy a website project from VS 2010 to a webserver it uploads App_Offline.htm file to the website folder so no requests are served to the user. After publish is completed that App_Offline.htm file is removed. During that period of time users see outage.
If we use CI on a live website then how can we eliminate that outage which appears to a user. I believe the whole point of CI is that users get to see newer features and the site is never down.
How is this accomplished? If we deploy website project to root folder then existing users will be affected and that is certainly no advisable.
I wanted to know what is the recommended practice with VS2010, TFS2010 Build & Version Control.
There's no real foolproof method for this, service up-time is never 100%, that's why people usually define it in 'nines'
But, if you had multiple web servers (Backup, fail-over, mirror etc.), you could roll out the update across them, so that as you update some servers, others will still be online (albeit with the old version) to serve users.
In general, only some of the largest websites have to worry so meticulously about being down for a few short minutes, so make sure you're focusing your energy in the right place ; )
Regarding taking down the site for the shortest time possible, the only way I've seen this done successfully is using multiple sites - either load balancing, or 2 sites on the same machine + swapping host headers after the release/warm up. But in most cases it's not worth the effort, releases shouldn't take down the site for more than a few seconds in which time there should be relatively few requests. You're better off trying a few things you can do to help your users live through a site release.
Move session out of proc.
If the users session lives in the app pool it will be lost when a new version is released, change the config to move it into a session server or the database.
Specify a machine key for the website
Viewstate (and cookies?) are encrypted using a key that is generated when a site starts, if a site restarts due to a release any users filling out a form will receive a invalid viewstate exception on postback. (Note: this may have other security implications)
I'm junior dev with little experience. I have a portfolio website with some examples of my work. As with many web applications, there's a login. I want to be able to publish the login credentials but have the database reset every half an hour if it's changed. This is to roll back the changes the user has made. As soon as I've published the credentials it maybe abused. The web app is written in php using Symfony
Am too sure how I should go about doing this?