I have created a folder that all users have full control over. In this folder is my backend, while the frontend resides on the local hard drive. I can open the database on my development computer, even over the network. On all other computers, the system simply loads the access welcome screen, or access opens and closes automatically.
Can there be virus protection or a firewall blocking this? I have enabled network connections, and allowed all vba projects, etc.
Can there be a reference issue? If I have a reference for an Outlook library, and have compiled the file into accde format, would this prevent any error messages and simply cause the database to fail? I can open the backend tables on all computers, it is just the frontend that will not open.
Any suggestions will be helpful. I am not at the site, so I will take all suggestions and try them when I return.
A few things come to mind:
Have a look in the Windows Event Log.
Another issue could be happening if the locations where the front-end is located has not been added to the list of Trusted Locations in MS Access.
If you put the accdb front-end on the user's machine, can it be opened? Do you get any error?
As you mentioned, there could be a reference issue. Try to remove the reference and convert your early-binding with late binding instead (use CreateObject).
Add some sort of logging to your application and log as much as possible to a text file from the startup sequence of your application. This may let you know if there is some of your startup code that fails.
Related
Have a client that upgraded all of their machines to Access 2016. Before, they had a mixture of older Access versions. The access databases they use have an ODBC connection to a Pervasive database. I don't know anything more about Pervasive. I know in the past when they've had a single machine go to Access 2016 or from older versions of Windows to Windows 2010 and I've had to re-link tables.
Right now, they're getting this error:
ODBC-call failed
[Pervasive][ODBC Client Interface][LNA][Pervasive][ODBC Engine Interface]Invalid date, time or timestamp value. (#0)
I need some suggestions on how to fix this for all machines and all Access applications.
** UPDATE **
The problem was a missing Active X calendar control. I changed all the date controls on the form to be text boxes to take advantage of the new Access calendar pop-up. The problem now is that the client has dozens of Access database. As far as I know, I'd have to open each file and each form in the file and change the controls one at a time. Anyone know of a way to update multiple Access file without having to touch them all?
The calendar control will still work with Access2016. If you've got loads of databases it's probably quicker to re-install the calendar control.
You will need the MSCAL.OCX file which you can download. Copy the MSCAL.OCX file to c:\windows\sysWOW64 not c:\windows\system32. Register it by running from the command prompt or run in the start menu
regsvr32 c:\windows\sysWOW64\MSCAL.ocx
and it should register OK but make sure that you run regsvr32 with administrator privileges.
I've written an application in Access 2013 (64-bit) that I'd like to split into front-end and back-end databases, storing the back-end on a file server where multiple machines can access the data via local instances of the front-end. None of the computers have Access installed, so I'm using Access Runtime 2013 on them.
The application runs fine when it is not split, on a single computer. As soon as I split the app into front-end/back-end files, the program opens and immediately closes on startup, with no error messages. I'm assuming that this is due to invalid links to the external data file on the first startup of the app (i.e. existing links are to folder locations on my development machine).
Has anyone experienced this problem? If so, is it due to invalid links? And, what can I do to allow the program to stay open, allowing the user to navigate to a form that I've provided in the main menu form for setting the path to the back-end file for re-linking tables?
In the load event for the menu form check if you can access the data by trying to open a recordset. If you can't, close the menu form and open your form for setting the database location. Make that there's nothing on you location setting form that is bound to the database.
I'm trying to deploy an SSRS report to a remote server (that is not on my network). I'm not sure how to do this. For a machine on my network, I would just change the TargetURL, but I'm guessing there should be somewhere that I can associate credentials to deploy to a remote server, but I'm not finding it.
I know this is an old post but if someone is wondering about the same question.
I am using vs2017 enterprise. So when you configure your remote url and folder name and everything is perfect to build your project, you hit F5 or deploy your project. Upon successful building vs will prompt you for your report servers credential. Then you do the usual and vs will do its own job. In a moment you will be able to access your report.
Just read about the permission requirements before you try it.
Hope it will help someone.
Thanks
I face a similar issue delivering reports to various servers (customers and dev,qa,staging and production.) In visual studio the best way to do it is start a new project for the new server and import the new reports into it. You end up with a new project for each server.
I found TFS / VS unwieldy and my workflow to manage it unfortunately is doing it manually, or using one of a few open source report uploading tools (there are powershell scripts to do it but I find the tools are more user friendly.)
Best thing to start with is doing it manually; which will sort your initial problem.
Save the file out of your report writer to disk.
In Internet Explorer log into the Report Manager of the remote server http(s)://remoteservername/reports and navigate to the folder you want. Then upload the report.
When its uploaded you may need to fix the connection to the database.
Once you get used to doing this you can use a tool like reportsync to easily and quickly move reports between servers.
Ive done a fair amount of searching on this, but ive struggled to find the answer.
At present I have an access program that sits on a remote windows 2008 server and users can log into it through a remote app. In the local version of my program, users can hit a button and email through outlook, but obviously if your accessing it remotely it tries to open outlook remotely.
So here's the question: Is there any functionality that will allow me to open Outlook locally whilst using the remote app?
Ive read about scriptable virtual channels but i would like someone to confirm if this is possible (or call me a moron for even contemplating the idea).
Thanks in advance.
Split the database. Your client will then open Outlook locally.
Here is some info that might be helpful if you do not know how to split the database and what the benefits are: http://office.microsoft.com/en-us/access-help/split-an-access-database-HA010342026.aspx
In my development environment, every time I reboot windows (which must be done at least daily for me), all of my Shared SSRS Datasources lose their credentials.
Currently I have them set up to log into the database using a fixed credential, but on reboot all the datasources pop over to using no credentials. Granted, it's only in the dev environment, and I can just check out/update the datasource/check back in and it will work fine... until I reboot again.
FYI, I've been using these Shared Datasources for at least 2 years and no problems, but in the last month or so, it's been a recurring daily problem.
Help?
I'm assuming you are talking about the Shared Data Sources in a Report Server project in Visual Studio, as opposed to a Data Source created directly on Reporting Services. The latter, the data is stored all in the ReportServer database that was specified when setting up SSRS.
Now, as for the .rds file used in Visual Studio, if you open the file up in a text editor, notice that the username and password is not stored in the file. It is actually stored in the .rptproj.user file. So, check that someone didn't remove the .user file from source control (.user files shouldn't be in source control, but in your case...).
This is scenario is testable by entering your credentials, saving all files, and exiting Visual Studio. Find and delete the .rptproj.user file, and open your Report Server project up again and see the credentials gone!
A work around is add the "User ID=user;Password=pass" as part of the Connection String. When the .rds is opened up, the Connection String won't show this portion, but the Credentials tab should have the right values.
Could this be related to the boot order of services on your machine.
Just a guess: Maybe there is new functionality in SP3 that checks if the connection credentials are valid. If they are not valid they are cleared.
The problem would then happen if this check is done before SQL server has had time to start. This would explain why they are cleared when the machine restarts.
I have recently experienced the same problem, but I can't connect it to a reboot. It seemed to happen when I checked the solution from source control - we use Team Foundation Server. After disabling the service account a bazillion times, it somehow healed itself and began behaving. I found this post and checked my project folder for the rptproj.user file that benson mentioned, and it has a modified date of the day I had problems, but a create date of close to what I can remember as having created the project, so I will pay attention to this in the future.
Did anyone come up with anything new on this issue?
I realize you may have read this already, but something here could help? http://msdn.microsoft.com/en-us/library/ms159846.aspx
I would pay attention to how the SSRS was installed and also what accounts the servies run as, as well as an domain logon policies.