Access 2013 failure to run query whilst application minimised - ms-access

When I run a report - using either a simple query, complex (query builder) or via DoCmd.OpenReport(.....) then the report populates fine.
However I wish to run the application with the forms etc as Pop-ups, and the application minimised, or hidden - otherwise users will just access the database that way - and miss the logic that is integrated etc.
So I am Minimising the application using apiShowWindow(hWndAccessApp, SW_SHOWMINIMIZED)
However in this case, when I run the same reports as before - there is no data, just a blank report - not even the header!
Any ideas?
Julie

Not sure why it works, or needs to be the case, but setting windows mode to Icon (via the macro and/or the doCmd.OpenForm () command in VBA) works.
Nor can I claim the credit - Thanks to Wayne G Dunn

Related

Is there a way to publish main and sub SSRS reports using report builder?

Dears,
I am quite new with Report Builder, and also with SSRS so sorry in advance if I raise irrelevant questions. My goal, essentially, is to deploy a sort of SQL Monitoring dashboard (I just uploaded a demo picture of it, here the link 1 ), that is composed by a main report with some charts and toggled sub reports. All these sub reports are filtered by the SQL instance name, and other parameters like number of monitoring days, months etc...
Plus I make use only of shared datasets.
Now, if I deploy the whole solution with Visual Studio against my report server, it works perfectly and all the report parts are uploaded without any issue against the report site.
If I try to deploy the report using the report website manager (by trying to upload the whole solution file by file), it does not upload anything, even if I create first the data source and then trying to add the existing datasets.
If I try to deploy the solution with Report Builder (after having giving to it the target report server URL and an existing folder that starts with slash), the only option I have is to open the solution as file, and save it against the target report server configured. But then the annoying error appears even if I the path has less than 260 char and even if the path starts with the slash:
"Error: The path of the dataset "" is not valid. The full path must be
less than 260 characters long; other restrictions apply. If the report
server is in native mode, the path must start with slash.
(rsInvalidItemPath)"
What am I doing wrong? I thought that a tool like that, used also for publishing, would make the life easier, but apparently I may not know exactly how to use it.

Formulare (German) vs Forms (English)

I am getting an issue running a Microsot Access Database (.accdb).
The application was made by a German colleague (using Ms Access in German language of course), now after I copied into my machine (I am using Ms Access in English language) I am getting the following prompts: "Enter parameters values" (see screenshot).
It is clear that the program is looking for values like "Auswahl_MinDate" , in the query I replaced all the code from "Formulare" to "Forms" - it has worked however it is still looking for 2 more values starting with Formulare.
I tried to check all the Forms, Query 1 by 1 however could not find significant results.
For example the 'Auswahl_MinDate' is a date picker control, hence I deleted and recreated but still...
Where else this 'Forumulare' could be set ?
Thanks.
If you can't find it in query parameters or SQL, it may be hidden in control properties.
Your best bet is probably a global search tool.
Search For Text (Free, open source)
https://www.utteraccess.com/topics/1992076
The 2nd post has an .accdb for Access 2016 (the original is .mdb)
You need to register to download the file.
Still available for download, but unfortunately not for purchase is Find and Replace by Rick Fisher (Shareware)
http://www.rickworld.com/download.html
V 9.00k also works for Access 2016 / 365.
I don't remember if it stops working after 30 days or just keeps nagging.

MS Access 2010 Ribbon Not Changing From Report To Form

In an application I have two ribbons: a "General" one which is used for all forms, and a reports-specific one for all reports. From a "Reports Manager" style form, a user can select a report and preview it.
When the report opens, it correctly displays the Reports Ribbon. However, when the report is closed, the Reports Manager form is still showing the Reports Ribbon, instead of the general one.
Once this form is closed, the Ribbon changes back to the general one.
Note that users access this application, as an accde, via Terminal Server.
This incorrect behaviour does NOT happen on a local development machine, so I suspect it is due to a TS 'refresh' issue - which I have noticed in a couple of other circumstances.
Is there anyway to 'force' a refresh of the Ribbon when a report is closed, and the Reports Manager form is therefore displayed?
I would consider in your startup code grabbing a handle to the main ribbon (that is not re-displaying). Then in the reports on-close event execute a ribbon invalidate command like this:
MyMainRibbon.Invalidate
So you can “force” a ribbon re-plot. This does suggest you always use a accDE, since with a accDB then any un-handed error will ALSO lose the above global var that holds a reference to the ribbon.

Report Builder 3.0 - Dataset Credentials Do Not Work

I am using SSRS 2008 R2 and Report Builder 3.0. I set up a shared data source via the browser (http://myserver/reports/) wherein the "credentials are stored securely in the report server" to use with multiple reports. Testing the connection via the browser works.
Now, I fire up Report Builder 3.0. I start a new report and "Add Data Source". I select the "Use a shared connection", browse to the server, and select the above data source. Click "Test Connection" and all is well.
I then try to "Add Dataset". In the dialog, I select "Use a dataset embedded in my report", I select my data source added above, type in the SQL string and click OK. The "Enter Data Source Credentials" appears. No matter what permutation of valid domain (like the domain admin account and others) or SQL Server (like the 'sa' account) credentials plus checkboxes I use, I get an "Unable to connect to data source".
Security settings on the shared data source allow BUILTIN\administrators and domain\administrator all roles. The data source does work, as some legacy migrated reports run fine. Report Builder says the data source connects okay. But, I cannot create new reports, nor modify existing ones.
Any suggestions?
After much gnashing and wailing seems like Report Builder uses information in definitions in Report Server to then run queries locally by itself, and not through Reporting Services.
My mistaken belief was that when I did something like Refresh Fields when setting up a Dataset, Report Builder was going through Report Services to get the relevant output and/or metadata. This seems to not be the case.
I had defined the connection string of the shared data source as Data Source=(local);Initial Catalog=<database name>. Now, this works when you are in Reporting Services' browser interface, but Report Builder seems to read the connection string and use it for itself. Reporting Services on my local development machine does not have any of the setup on the target server running these reports, so anything I would use will fail.
Changing the connection string to Data Source=<server name>;Initial Catalog=<database name>, instead of localhost, allowed Report Builder to work properly. (RB still popped up "Enter Data Source Credentials". I used my Windows credentials, which is a valid login on the target server.)
To accomplish what you are attempting, it sounds like you will need to use windows integrated security.
According to MSDN stored credentials are not passed to client applications. They are for use only by the report server for things like scheduled reports.
http://msdn.microsoft.com/en-us/library/ms159736.aspx
I can tell you that the prompt "Enter Data Source Credentials" is looking for SQL authentication, not domain accounts.
Outstanding question and answer. I really appreciate your careful description. I had the same problem. In my case the problem was that I was accessing Report Builder from a machine connected to my home office by VPN. I guess because I was outside of the Windows network of the home office, RB couldn't authenticate me. Working with a Remote Desktop connected to a machine at the office allowed me to side-step the problem. Your and #RichShealer's answers reminded me that when running the reports from the browser, they're being served up by an inside server machine. This is not the case when running RB, a desktop app.

SQL Server Reporting Services Default Values From Query not working in deployed report

In order to populate a textbox in a page header I am setting up a parameter (as you cannot use Fields) and referencing this in the textbox. The parameter has the Default Value set to "From Query" and the Dataset and Value Field are set accordingly. This works a treat in developmentt in Visual Studio 2005. Once I have deployed the report and am viewing the report in the ReportViewer control I get the error:
"Parameter validation failed. It is not possible to provide valid values for all parameters. (rsParameterError)".
If I remove the parameter, the report works fine.
(Strange thing is that I thought I had this working earlier).
You've probably checked, but has the default value copied over? I've had issues in the past with reporting services where the default values were lost when I moved a report from one box to another.
Thanks for the answer - it has pointed me in the right direction...I have been using my own program to deploy multiple reports so rarely look at them via the Report Manager website. Anyway - I just deployed the report on my home PC and it worked fine....looking at the report in Report Manager on both PCs I found that "Prompt User" on the PC that wasn't working was not ticked...go figure. Ticking this resolved the problem.
I am liking the results that I am getting from SSRS, but I am quite new to it and am finding some things (like this) a little frustating...mouse and keyboard are lucky to not find themselves thrown out the window!