Every application I use to initiate an ODBC connection that I've created to my IBM Notes 9 DB results in getting an error during connect:
Driver's SQLAllocHandle on SQL_HANDLE_DBC failed
I have scoured the web trying to correct this and have not been able to find an answer that solves for this issue on my machine. I am able to open and access the Lotus Notes DB within the Notes 9 software. I am able to create the ODBC System DSN and I know that it's connecting to the server properly because all of the available .nsf files populate in the "Database:" dropdown menu when going through the new ODBC connection setup. I am able to see my username which gets populated from my Notes ID file. The issue occurs when I use something to initiate the ODBC connection. I have tried Excel, QlikView, AQT, Teradata SQL Assistant all with the same result. Once I choose the ODBC connection that I've created, and click on "Ok" in each application I've attempted this with, I am met with the same error above.
I used Event Viewer per a suggestion in an older post online and received the message below:
Could not load NSQLE32.EXE. This file must exist in the same directory NSQL32.DLL and NSQLV32.DLL is in. It is possible NSQLE32.EXE could not be loaded because NotesSQL couldn't locate a valid Notes/Domino installation (couldn't find NNOTES.DLL) -- this may be because user (MYUSERID) does not have the correct rights to the Notes/Domino directory. It could also be because NotesSQL can not find your Notes/Domino installation in the Registry. NotesSQL looks for the NNOTES.DLL file by looking in the path pointed to by the following Registry entries -- HKEY_LOCAL_MACHINE\Software\Lotus\Notes{version}\Path : HKEY_LOCAL_MACHINE\Software\Lotus\Domino{version}\Path. If neither of these registry entries exist or they point to an invalid version of Notes/Domino NotesSQL will not work. To resolve -- please re-install Notes/Domino.
Some notes (no pun intended) and things I've done:
Verified that the DLLs mentioned in Event Viewer do exist in the proper directories.
Run the Nsql_ALM.exe application to configure the NotesSQL driver.
Used the 32-bit ODBC Administrator because my Notes 9 is 32 bit, as well as the driver. The 64 bit driver would not even allow installation (attempted this after hitting this roadblock) but the 32 bit installed successfully.
Modified my System Environment Variable for Path to include the true location to notes.ini, which resides in:
C:\Users\MYUSERID\AppData\Local\Lotus\Notes\Data
Modified my System Environment Variable for Path to include the location to the NotesSQL driver, which resides in:
C:\NotesSQL
Modified my registry to ensure that the appropriate strings exist to reference the proper files:
HKEY_CURRENT_USER\Software\Lotus\Notes\NotesIniPath (to notes.ini)
HKEY_LOCAL_MACHINE\SOFTWARE\Lotus\Notes\9.0\Path (to notes application)
HKEY_LOCAL_MACHINE\SOFTWARE\Lotus\Notes\9.0\DataPath (to notes.ini)
HKEY_LOCAL_MACHINE\SOFTWARE\Lotus\Domino\9.0\Path (to notes application)
HKEY_LOCAL_MACHINE\SOFTWARE\Lotus\Domino\9.0\DataPath (to notes.ini)
Set the NSQLE32.exe application to run in compatibility mode with all other options.
Attempted with everything run as administrator.
Uninstalled both Notes and NotesSQL and reinstalled everything cleanly again.
Attempted a log via Tracing within ODBC Administrator and it will not create a log file when I am attempting the connection. It will populate, however, with all of the system ODBC connections when the calling application attempts a lookup of the existing connections to populate in the dropdown menu. If I start tracing after the dropdown menu has been populated, then attempted the ODBC connection, even multiple times and with multiple versions, a new log file is never created.
I'm not sure where to go from here. Has anybody had this issue and is there something else that I can do in order to fix it?
I was able to correct the issue based on information in the Event Logs (Windows - Application) indicating that the Notes.INI file could not be located. I first added the location of notes.ini to the user and system environment variables, however, the issue persisted. I then moved notes.ini to the c:\NotesSQL folder where database connectivity dll's such as NSQL32.dll are found. This corrected the issue.
The application calling notes is SAP BusinessObjects Edge (Enterprise - Crystal Reports) 4.2 SP07.
notes.ini can not be found - Windows application event log
Related
I have a OLEDB task that connects to ms-access database on local file system and dumps data into sql database.
Access db connection string is: Data Source=\\my-share\accessdbfile.accdb;Provider=Microsoft.ACE.OLEDB.16.0;
The SSIS package runs OK in visual studio. Access 2016 32-bit runtime is installed on this computer.
After deployment to SSIS catalog, right click and execute works OK. Access 2016 64-bit runtime is installed on this computer.
When this package is scheduled to run via SQL Agent job, using proxy/credential [domain user - example: domainname\user1] (having read permission on the access db file), then the job fails. The SSIS execution report shows error as: Unexpected Termination. There is no further information.
Suppose if I add the proxy credential (domainname\user1) to the local administrators group (in computer management) then the SQL Job runs OK. What could be the solution to this so I can give only the minimum required permissions?
The error is very difficult to debug as it doesn't occur when running via visual studio. Even when deployed to the SQL server and run from the SSIS catalog, the execution works OK. The error occurs only when the package is run via SQL server agent job (via credential/proxy) - the SSIS execution report doesn't show any helpful messages; and surprisingly the error gets resolved when the credential is added as local administrator on the computer - which is a bad practice.
The solution is analyse what kind of ms access file you are using and appropriately use the correct access runtime version (2013 vs 2016) and the correct provider value in the connection string.
Access runtime:
In my case, I uninstalled Access 2016 64-bit runtime and installed Access 2013 64-bit runtime.
Provider version:
I changed the provider version from 16.0 to 15.0, as shown below-
Before: Data Source=\\my-share\accessdbfile.accdb;Provider=Microsoft.ACE.OLEDB.16.0;
After: Data Source=\\my-share\accessdbfile.accdb;Provider=Microsoft.ACE.OLEDB.15.0;
Note:
There is no need to add the user to the local administrator group.
There is no need to login to the computer using that account.
Only read permission (under windows folder security) is sufficient assuming the SSIS packge will only read the ms access database.
It's hard to debug this only with the information provided, but in general:
The user running the job requires at least write and delete access on the underlying folder in which the Access database resides. This is required to generate a lockfile for the database.
If this is undesirable because the job may be modified by a malicious user, I've seen deployments where a copy is made in a temporary folder with write access and a size quota, and that temporary folder is removed as soon as the job finishes, regardless of if the job succeeded.
I appear to be unable to get my deployed SSIS package to read from a 1997-2003 Excel file.
I get stuck with the following 2 errors:
SSIS Error Code DTS_E_OLEDBERROR, Error code: 0x80004005 An OLE DB
record is available. Source Microsoft JET Database Engine, database
engine cannot open the file, it is already opened exclusively by
another user, or you need permission to view its data.
DTS_E_CANNOTAQUIRECONNECTIONFROMCONNECTIONMANAGER with Error code 0xC0202009
The package itself works with no issues when using SQL data tools on the server logged in as the service account only when deployed to server I see this issue.
To make this issue even more confusing I have setup and tried the following:
Runtime is set to 32 bit on the debugging menu on SQL data tools as well as the job configuration is set to use 32 bit runtime
I am able to UNC to the folder/file when logged in as the SQL service account
Any Ideas?
Thanks,
M
I figured it out in the end. Turns out I missed a step with the permissions.
Yes the Service account had permissions to the folder but I failed to add read permissions to the file itself.
Thanks for all comments/suggestions.
M
Let me lay out the background details first.
I'm using visual studio 2013 to write a vb.net windows forms application to load a crystal report (.rpt) file. The main report and sub report uses a SQL command from a Pervasive database (through an oledb connection) as shown in the picture below. For privacy, I've changed the database name to DBNAME.
I installed SAP Crystal Reports Runtime Redistributable 13.02 on the client computer. Obviously, I have the developer version on my computer.
Everything seems to work just fine when I run the build from my computer (the one used for developement), but when I try to run it on the client computer I get a window like the following:
So a few things to note here:
On the development computer, this prompt doesn't appear.
For some reason the database name shows up where the file server name should be
I never set a username or password, nor have I ever needed one to access this database through the control centre from any computer on
the network
no conceivable combinations of usernames and passwords work (including network credentials, windows credentials, and leaving it
blank)
I've tried forcing the credientials in the viewer form load event
CrystalReportViewer1.ReportSource = rpt
rpt.SetDatabaseLogon("", "", "FILESERVER", "DBNAME")
rpt.Subreports("Subreport2").SetDatabaseLogon("", "", "FILESERVER", "DBNAME")
rpt.Load()
but it doens't seem to make a difference. What am I missing?
Ok, I got it. Thanks to Bugs for pointing me in the right direction. The problem was with the connection type in the report. Changing the connection to ODBC (RDO) using 'right click > Database > set Datasource location' got rid of the credentials prompt, but instead caused a "Failed to open the connection" error. From there I looked for differences in the ODBC administrator from the pervasive control centre. I found that I had a system DSN that happened to have the same name as my database (which is why it confused me). Creating the DSN on the client computer resolved the connection problem.
I have installed CouchDB on my Windows machine but while starting the CouchDB service, I am getting a message like:
Windows could not start the Apache CouchDB service on Local Computer. The service did not return an error. This could be an internal Windows error or an internal service error. If the problem persists, please contact your system administrator.
As the service is not running, I am unable to access Fauxton too.
I am using Windows 7. CouchDB is 2.0.0. Port 5984 is not in use.
I don't think your question is a duplicate of https://stackoverflow.com/a/44107335/219187 because you are on Windows 7, and the problem described there is for Windows 10 with the creators update.
But maybe the solution fixes your problem as well? Here is the procedure:
Download the prelease build 2.2.4-101 from https://nssm.cc/download
Stop the CouchDB service through the Windows Services dialog (paused is not enough)
Overwrite nssm.exe in <CouchDbInstallDir>\bin with the one from the downloaded ZIP file (make sure you pick the right version 32 bit / 64 bit)
Start the CouchDB service
Issue it's happening since the last updates released by Microsoft. I'm not completely aware of what's causing it, but I think it's something related to CouchDB service not been able to start using Local Administrator rights.
However I've managed to start the service manually, by doing so:
Open Command Prompt - in the Search from the Start Menu or Task Bar type "cmd"
Run it as an Administrator - right click on the Command Prompt application and choose "Run as administrator" option /this is really IMPORTANT as it will allow the service to have administrator access/
Navigate to the folder where CouchDB is install - default path is "D:/CouchDB", but could be anywhere else; you have to find it
Go to the "bin" folder in there
Type "couchdb" as a command to start the service
You will see a message showing after this - "kernel-poll not supported; "K" parameter ignored"
If it adds some error messages after it or closes the whole terminal, you're making some things bad from this guide, so follow it strictly.
You can now open up the Fauxton application in the browser like normal from here - http://localhost:5984/_utils/
Keep in mind that you have to leave the cmd opened in order the service to be working as expected. As far as I saw no information was lost, so it's all good.
This is a temporary solution though, as we are waiting a relase from either Microsoft or Apache to solve the issue, or at least give us more explanation about it.
i just met the same problem.
the cause is space, you have to install CouchDB in a path without any space, even Program Files folder, because there is a space between Program and Files...
I've made VB.NET application in VS2010 that uses a 2007 Access database, called MenuDB.mdb. During development, everything was fine.
Now that I'm publishing it, I'm getting weird errors because for some reason the app isn't connecting to the database.
I install the application and run it but as soon as it opens it gives this error:
System.Data.OleDb.OleDbException (0x80004005): Could not find file
'C:\Users\Administrator\AppData\Local\Apps\2.0\Data\OV86PXJA.K3R\8575R5AY.95Z\menu..tion_0d4fa454d69e8e6b_0001.0000_8340d263807cbb71\Data\MenuDB.accdb'.
I know the problem has to do with the way I'm relating the application to the database, but I don't know which way is right. In Solution Explorer I changed the Build Type of MenuDB.accdb to "Content" (earlier it was embedded resource". But it doesn't work either way. In my App.config I have the following connection string:
connectionString="Provider=Microsoft.ACE.OLEDB.12.0;Data Source=|DataDirectory|\MenuDB.accdb"
I want that when I deploy the application, the database should just sit in the application folder, wherever it gets installed. How can I do that?
Edit
I don't mind deploying it in such a way that I need to paste the database somewhere myself on the target machine - as long as it works.
If you have multiple users using the same or similar database, and dont have access to a SQL server (MySQL, MSSQL, or others), then co-locate the database at a central location (preferably network location) that all the users will have access to and change the connection string to accomidate the database location being on the network.
Just let it be known, Access can handle up to 10users when doing simple data retrieval/submission but if you ever have it open while others are accessing via data objects, then you may lock them out.