I was wondering if I can connect Power BI server (not desktop) directly to the database I use.
By doing this, if possible, skipping going through pbi desktop.
And one more thing, can I share the dashboard as a secure link ?
I'd like to share the dashboard directly and in a simpler way so I won't run into people not wanting to use powerbi and have more flexibility with it.
Maybe someone can answer those questions for me so I won't have to keep wondering.
Thank you in advance!
In case it wasn't clear I m new to powerbi so if these questions sound like fantasy you know why..
This monday I installed my Power Bi gateway which is connected to my local drive (C:/). I uploaded my online PowerBi analysis on microsoft sharepoint. Everything works perfectly.
My next step is to install the gateway for my network drive because that way my PC doesn't have to run once the autorefresh is supposed to refresh. I have a problem, I can't get the gateway on my network drive. Someone else already asked this question on stack overflow but there where no answers, that's why I want to ask it again.
I can change the path of my Power Bi analysis to my network drive and I can also upload the files to app.powerbi.com, that's not the problem.
If you have questions don't bother asking.
I hope to hear from you soon.
I had 2x reports using Gateway where 1x would not connect to my work's network. The other report ok. I re-confirmed credentials and access rights and all were ok. Therefore, it was a problem with the 1x report somehow. I then gradually stripped my report down and eventually found the problem. It also used a SharePoint Excel file to obtain some data, it was having this SharePoint file along with a network data source that caused the problem. As soon as I removed the SharePoint link, everything worked ok! This is annoying because the spreadsheet was far more accessible via SharePoint. The best debug you can do is to 1) check you data source settings and ensure you're logged on to all of them, 2) strip your report back until it works, 3) create a super-basic report by grabbing one data source from your network and using a basic table to display contents.
hope anyone can help me.
I tried now several times to import my first Power BI model into AZURE Analysis Services. I went through the steps as described by the AZURE team. After I've chosen the right server and the model as PBIX file from my local drive and clicked on import, the following happens:
1. It is running for several minutes.
2. After several minutes it stops without any message or anything similar. The model is afterwards not in AZURE Analysis service.
I tried it now 4 times without any success.
Has anyone made the same experiences? Does anyone know a solution for that?
thanks and br
Christoph
There is a fairly short time-out on the import option for Azure Analysis Services. If it is a large model, I typically:
Export model as a template (pbit)
Open PBIT, and select edit instead of load.
Save new pbix without applying changes or refreshing data.
This new pbix should be small enough to import as long as there aren't any other issues with the dataset.
I installed Power BI Gateway in order to use SQL directly in my Dashboard. I published the report and found that none of my colleagues could view it without a Pro License. I tried everything but can't get rid of the so called "power BI pro content" in my dashboard.
So I uninstalled the gateway software and reinstalled Power BI.
I tested by creating a very basic report with one line chart linking to excel. Even this report can't be viewed by my colleagues because "it contains pro content".
As it turns out, ALL dashboards (even created by my colleagues) give this warning when I try to share it.
This is driving me nuts. Please can someone help.
thanks
g
The documentation for what counts as Power BI Pro content is here: https://powerbi.microsoft.com/en-us/documentation/powerbi-power-bi-pro-content-what-is-it/
Some key tripping points: anything with a scheduled refresh that uses a gateway, or that refreshes more than daily counts as Pro. Anything posted to a group workspace or shared via an organizational content pack count as Pro too.
Bear in mind that a dashboard only needs one tile from a "Pro" report to be considered Pro.
In an enterprise setting, where your data is coming from SQL on-premises, it'd be hard to avoid pro content. Your data would have to be imported into Power BI Desktop, and refreshed & republished manually. You couldn't use direct query mode, a gateway, automatic refresh, group workspaces, or organizational content packs.
It's hard to comment specifically on why your very basic Excel report contains pro content. If you're sure it doesn't meet any of the documented reasons, click the Smile at the top-right of PowerBI.com and Submit an Issue. Microsoft should be able to tell you.
Note: What makes content pro could easily change in the future, so although I highlighted some common tripping points, I do recommend referring to the linked documentation for the definitive answer.
Before you start flaming, I'm going to tell you that I am trying to convince myself that this is a bad idea.
Basically, I'm trying to create a website with some basic accounting functions. My friend, a consultant who only knows excel, asked if this could be an excel spreadsheet instead of a web interface.
I found myself thinking, why is excel not the better tool in this case? It has all the tools a web2.0 app has (scripting, access to a db, basic formatting), and is made for accounting. You could basically use excel to write a program that fetches data from an SQL database, populates some cells, and use formulas for the rest.
Is there precedent to using excel as one would use the browser to make an ajax-y web2 app?
Why is this a bad idea?
Update: just to clarify I meant this to be more a "rhetorical" discussion. I'm not sure why the rest of the message didn't clarify that...
Well, if you made it in excel, then it wouldn't really be a web application. It would be an Excel application.
Not that that's a bad thing though. If it makes more sense to build the app in Excel, then go for it.
The problems you'll have doing it in Excel will be the same as the problems you run into with any desktop vs. web application. For example, How do you handle deploying new versions of the app? How do you handle updating the app for new (or older) versions of Excel? etc.
ETA:
If you want to avoid the bugginess of Excel VBA and the headaches of managing a desktop application, you might want to look into the Google Spreadsheets API. You can use it to create/update Google docs spreadsheets on the fly, including formulas and lots of other spreadsheet goodness. Using a hybrid of web application and Google Spreadsheets might give you the best of both worlds, depending on what exactly you need to do.
After years of programming in Excel-VBA, the best answer that I can give you for not doing this:
Excel-VBA is buggy! It is probably the most bug-filled app that Microsoft has produced. It's great for some tasks, but forcing it to do a job for which it was never intended will lead to trouble.
I have a few spreadsheets that do similar things, (things Bill never intended), and without exception, they teeter on the brink of failure, and tend to crash with only the slightest provocation.
Sure, you can do it, but the headache is not worth it.
Excel was not meant to be used that way, so it will be painful.
Two better ideas for web-spreadsheet integration:
Take a look at Resolver One, a programmable Excel-compatible spreadsheet with an integrated web server.
Use Google Docs spreadsheets. There is an API to interact programmatically with them.
It's not a bad idea, but it does come with some limitations. If deployment isn't an issue for you, and you don't need "universal" access to the application, your solution will likely save you some time. A web application would certainly be a more elegant approach, particularly if you want to make the software available publicly.
The web is inherently based on HTML and added to with Databases, CSS and server-side languages and javascript (possibly others). As with most things, you should use the right tool for the job. If you want a website then you should use the tools for creating a website.
Excel is not meant to make websites, forcing it to do so will likely lead to more frustration than happiness.
Well, you're going to run it on the server side, you'd probably run into licencing and performance issues.
If you're delivering .xls to the client, then you'd need for all your clients to have Excel or something compatible. But you also lose control over your "site" - what's the point of visiting if you have everything you need locally?
So, the SQL statements would be on the client? That's rarely a good idea.
It's a bad idea for the same reason that writing a graphics editor with MS Access is bad, or coding a MMORPG using Powerpoint is bad :)
I would also say that once you stop using a browser as the client it ceases to be a "web application" - you are really just talking about an Excel sheet which fetches its data via HTTP.
+1 to everyone who said "an excel app is not a web app."
BUT... If you want to use the spreadsheet metaphor for server-side calculations for a web app, or if you want to access the library of financial functions that come with Excel from server-side code, you can use Excel Services. It's exposed via SOAP, interoperable, callable from any SOAP-capable platform.
It's server-capable. It does not actually load Excel on the server, but a non-GUI runtime of the functions.
I think that using Excel as Browser is bad idea, however i think better idea is to use Excel Control in Desktop App.
This way you can control the sql and connections. you can save data as often as you like. you could also implement some update mechanism. App would be more secure and harder to hack.
I think Excel freezes when you try to connect to some outside resource and this way you would control everything.
Did you start by getting user requirements for this application? It doesn't sound like they wanted a website to begin with. Sounds like they wanted an excel spreadsheet with macros.