The following error message was constantly appearing for me while trying to run the following OLE commands from AHK:
acc := ComObjActive("Access.Application")
acc.DoCmd.OpenForm("frmSearchLayer",0) ;acc.DoCmd.OpenForm("frmSearchLayer",acNormal)
When closing down my applications I noticed one of my VBA windows was currently open meanwhile being still connected to a COM object from the same database I had been trying to access.
The method to solve my user case:
Check task manager and quit all instances of MSACCESS.EXE
Related
When I execute a package in Visual Studio it works fine. However, when executing that package in SQL I run into this error "Cannot update. Database or object is read-only." and the Subcomponent name for this error message, is Excel Destination.
I tried adding "IMEX=0;Readonly=False", to the connection string of Excel Connection Manager but didn't help
I saw this https://stackoverflow.com/a/42654325/12021687 and I know my database is read-only (which I can't change) but I don't believe it relevant to me as the Subcomponent name of the error message is Excel Destination.
Can someone guide me on what may be causing this issue?
Permission Issue. Package may not be running under the user you are expecting.
Try changing the security permissions of the file/folder to full control for NT SERVICE\SQLSERVERAGENT.
Rerun the package. If this works check who the file was last saved by and give this user the required permissions.
p.s. Very Frustrating issue for myself too!
Edit
Also before I found the above as soloution:
I set DelayValidation = True everywhere in the Project.
Added ;READONLY=0 on the connection string
I have created an export task to export a view into an excel file onto a folder location. The task runs fine and exports to excel in the correct place. I ahve now saved this task in SSIS.
I am now trying to create a SQL agent scheduled job to run the task daily. I have SQLServerAgent and MSSQLServer access to the folder location however it keeps failing with the error:
Executed as user: NT Service\SQLSERVERAGENT. The process could not be created for step 1 of job 0x3FF5419F86864B47A653A928777E56DE (reason: Access is denied). The step failed.,00:00:00,0,0,,,,0
I have looked this up online and there were suggestions to try ticking the use 32bit runtime checkbox which i have also tried and still keep getting the same error.
Does anyone know what i can do to get the SQL agent job to run successfully?
I found the cause. The reason was I gave SQLServerAGent read/write access to the folder but it needed modify permission. Once i gave it modify it worked fine
I can't open an ACCDB file I have - I just receive a message saying:
Record Deleted
I've tried compacting it from the command prompt to no avail.
Can anyone help?
This database almost certainly has a startup module defined that is executing some code. You can bypass this and open directly to the database window by holding the SHIFT key down while opening your database.
https://support.office.com/en-us/article/bypass-startup-options-when-you-open-a-database-ba66917a-68b6-4fe6-8c23-33042953a5f9
I'm trying to get a windows Scheduled Task to open up MS Access DB (.mdb) which has an AutoExec macro that runs some queries and then exports it to a .csv replacing the .csv file that is already there.
From the command prompt I can run:
"C:\Program Files (x86)\Microsoft Office\root\Office16\MSACCESS.EXE" "/Path to my Access DB"
and everything works perfectly. Access opens up, runs the query, and replaces the .csv with new data from the query.
When I try to do this with a Scheduled Task access just deletes the .csv file without ever replacing it and returns the error "the operator or administrator has refused the request".
Any ideas? I was looking for a quick way to get the data but I feel like I might be better off just writing some python to connect to Access.
I was able to return to this problem this week and finally found the solution.
The problem came down to the scheduled task. It was a local machine permissions issue and running the task with the correct domain that solved it.
First to fix the local machine permission I had to make sure that the user running the task had "Log on as a batch job" permissions.
Found at Control Panel -> Admin Tools -> Local Security Policy\Local Policies\User Rights Assignments -> "Log on as a batch job"
Second, because I was on a domain the schedule task had to be explicitly created by the domain user. I had to manually find the user on the domain during the creation of the task and remove the user that was auto populated by the task scheduled creation wizard.
Having some SSIS permissions issue.
I am calling the SSIS package in my .net console application with:
Package pkg = app.LoadFromSqlServer(packagePath, serverName, serverUsername, serverPassword, dtsEvents);
It is working when manually running it using the windows accout, but fails with the above call in my console application.
Shouldn't it work with the sql server sa account?
There are plenty of reasons for it to fail when run under different account, to avoid trying to fix it blindly, you should get the error information. It looks like you are supplying dtsEvent parameter - so your app should get the error message. Another way to get it to examine package.Error collection after execution, or enable SSIS logging and check the error log.
Once you have the error message, update the post :)
There is also a KB article dedicated to troubleshooting such errors:
http://support.microsoft.com/kb/918760/.
But it just lists lots of possible error causes - to find out your issue, you need to get the error message first.
This generally happens when you have sql queries that use linked server to access a database on a different server.