I'm trying to deploy the Sybase SQL Anywhere 10 Runtime Engine, but I'm having some problems. When I run my application, I get an error:
SQLSTATE = IM003
Specified driver could not be loaded due to system error 193 (cinema_ConfigurationDriver).
According to my research, this is indicative of a missing DLL. I am looking at documentation on what and how to deploy. That documentation is from the Sybase SyBooks Online site
I have copied the indicated file into my application directory. I have also created the registry entries as indicated with two changes. Instead of calling the driver SQL Anywhere 10.0 I have called it cinema_ConfigurationDriver.
And I did not create the DSN entry; I am using a DSN-less connection in my PowerBuilder 11.5 code.
I know zilch about PowerBuilder, and I have no idea what "cinema" refers to, but I do know that there are no error messages in SQL Anywhere that contain "cinema". However, "Unable to start specified database" is definitely a SQL Anywhere error message. Can you post the full contents of your connection string? (You can either update your question or add a comment to this answer.)
Edit after OP comment:
You don't need to specify the -ga switch, since the client library will add it for you (unless you use the AUTOSTOP=NO connection parameter), and you shouldn't add the -n switch to the START line, since that's what the ENG parameter is for. Neither of these will cause your problem however. The obvious thing to check is that you've specified the correct path to the .db file and that you have permission to modify the file. If that's OK, you could add the LOG=<filename> parameter to the connection string, and then check the contents of that file for more detailed information.
Related
I am trying to synchronize two Firebird databases with each other. First of all, I already configured that the synchronization will be one-way. Therefore, one database is the Source-DB and the other is the target-DB.
To start a synchronization I use IBReplicator! When I start the synchronization, I get the error:
Exception: Invalid token
invalid request BLR at offset 340
function F_LRTRIM is not defined
module name or entrypoint could not be found
I started searching for the cause of the problem. What I already checked:
.dll files exist in the firebird directory
Firebird version is 32 - bit
IBExpert displays the UDF in the UDF Section of the database.
I read that it could be a problem when there is a mismatch between Firebird Server version and .dll file version. But I don't know how to verify the versions.
And I wanted to search for a .conf file to check the path for the UDF file (.dll) but I didn't find it. I only found the firebird.conf file and I already set the UDFAccess to Full.
I would really appreciate if someone could help me. I wasted a huge amount of time in this problem.
The error means that Firebird can't find the entrypoint or library when the function is executed. This means that
The library can't be found: it is not on the (library) path or in one of the folders listed in the UdfAccess configuration
The library was found, but it is 32 bit and you're running 64 bit (or it's 64 bit and you're running 32 bit)
The library was found, but doesn't have the entrypoint for the UDF.
Your problem seems to be the first, and the solution is to add the location of the UDF to the UdfAccess configuration. Given the comments, you should use
UdfAccess = Restrict UDF
Which will only allow UDF libraries from the UDF directory of your Firebird installation. If needed you can list multiple directories separated by ;.
You should never use UdfAccess = Full, it is unsafe as it can possibly be used to compromise your system with any library on the (library) path of your system.
Why did I get below error? This error doesn't always happen. It occurred only once. This error came from ResultSet.next(). I am doing some research about it but I couldn't find the main reason. Here is the link that I found for same SLQCODE and SQLSTATE.
DB2 SQL Error: SQLCODE=-1476, SQLSTATE=40506, SQLERRMC=-293, DRIVER=3.63.123
at com.ibm.db2.jcc.am.fd.a(fd.java:666)
at com.ibm.db2.jcc.am.fd.a(fd.java:60)
at com.ibm.db2.jcc.am.fd.a(fd.java:127)
at com.ibm.db2.jcc.am.vn.b(vn.java:4031)
at com.ibm.db2.jcc.t4.db.h(db.java:286)
at com.ibm.db2.jcc.t4.db.a(db.java:244)
at com.ibm.db2.jcc.t4.db.c(db.java:31)
at com.ibm.db2.jcc.t4.r.a(r.java:32)
at com.ibm.db2.jcc.t4.j.Zb(j.ja
DB2 version: DB2 v10.1.0.4
OS: Linux
The underlying error (that caused the rollback) is the -293, which corresponds to SQL0293N (error accessing container). You need to check the details at this link of the documentation.
Don't ignore this error-message, you want to find root cause, from database diagnostics files.
It may be that the issue is only with one specific container that gets occasionally accessed. Or it may have been a temporary issue according to how the container is implemented (file-system, raw, san, device etc).
If your Db2-server has good alerting at operating-system, file-system, and Db2-level then there may have been alerts about the underlying issue.
If the Db2-server runs on Linux/Unix/Windows, then search in the diagnostics files for references to the -1476 and then find other preceding messages. That usually gives more details. You can use the timestamp of the error message to narrow down the diagnostics location where you may find more details. If you find that information, edit your question to include it. You might also add details of the Db2-server version and the operating system on which it runs.
I am trying to get the Zumero for SQL Server working and I cannot get past running the test client. I get the below error
Connection string in web.config is
<settings temp_directory="C:\ProgramData\Zumero\ZSS Server\temp\"
odbc_connection_string="DSN=krishna;User Id=syncadmin;Password=syncadmin;"
license_key="<removed>" />
The description for Event ID 1 from source Zumero cannot be found. Either the component that raises this event is not installed on your local computer or the installation is corrupted. You can install or repair the component on the local computer.
If the event originated on another computer, the display information had to be saved with the event.
The following information was included with the event:
Error -1 (mssql): {"diag":[{"SQL_DIAG_MESSAGE_TEXT":"[Microsoft][ODBC SQL Server Driver][SQL Server]Cannot open database \"ZumeroTest\" requested by the login. The login failed.","SQL_DIAG_NATIVE":4060,"SQL_DIAG_SQLSTATE":"42000"},{"SQL_DIAG_MESSAGE_TEXT":"[Microsoft][ODBC Driver Manager] Driver's SQLSetConnectAttr failed","SQL_DIAG_NATIVE":0,"SQL_DIAG_SQLSTATE":"IM006"},{"SQL_DIAG_MESSAGE_TEXT":"[Microsoft][ODBC SQL Server Driver]Invalid connection string attribute","SQL_DIAG_NATIVE":0,"SQL_DIAG_SQLSTATE":"01S00"}],"SQLRETURN":-1}
..\..\..\src\core\sg\sg_mssql.c:344
..\..\..\src\core\sg\sg_mssql.c:384
..\..\..\src\core\server\zum_db_mssql.c:2896
..\..\..\src\core\server\zum_respond.c:4454
..\..\..\src\servers\iis\main.cpp:1211
The publisher has been disabled and its resource is not avaiable. This usually occurs when the publisher is in the process of being uninstalled or upgraded
Either the SQL Server user doesn't have rights or the database doesn't exist.
You can use a DSN, but for troubleshooting purposes I recommend putting the connection details directly in the connection string for now. Once it's working you can migrate the settings back to a DSN if you like.
Looks like you're using SQL Server authentication. So the odbc_connection_string value should look like this:
Driver={SQL Server Native Client 11.0};Database={database};Server={server.ad.domain.com};UID={sql_server_user};PWD={password};
The database must exist and the user specified must have appropriate read/write access to it.
(If you're setting minimum necessary permissions, you'll also want to make sure the user has VIEW SERVER STATE rights, as described here.)
While unrelated to your invalid connection string problem, the messages about The description for Event ID 1 [...] and The publisher has been disabled [...] indicate that ZSS hasn't been correctly registered with the Windows Event Viewer. Did you install the server by hand (from the .zip file) or using the installer?
You can fix those messages using the following command (which probably requires an admin prompt):
wevtutil im "PATH\TO\events.man" /rf:"PATH\TO\zumero_server.dll" /mf:"PATH\TO\zumero_server.dll"
where PATH\TO is the path where you extracted those files from the .zip. If you used the installer then they should be located at: %PROGRAMFILES%\Zumero\ZSS Server
If you installed manually from the .zip then it's worth noting that the instructions had a subtle typo in that command which would cause it to fail. That typo has been fixed in the past few days, but it may have caught you during your installation and caused this issue.
After upgrade our IBM System i (aka i5/OS or AS/400) from V5R4 to V7R1, one of our applications that connect to DB2 using ODBC fails with the following error:
Error Code: 69899
SQLSTATE: S1000
[IBM] [System i Access ODBC Driver] [DB2 for i5/OS] PWS0005
Error occurred in the database host server code.
The symptoms are:
In a While / Wend loop a CURSOR is declared, then opens, do fetch(s) and close.
If at any iteration the cursor does not retrieve any rows, in the following iteration the error occurs after declaring the cursor (with a different SQL query) when you try to open it.
First we updated the ODBC driver to the latest version available, but the problem persists.
Because we needed an urgent solution, I solved the problem by making a pre-select to determine if the cursor will return rows, otherwise skip that iteration, this solves the problem for now but does not seem a very elegant solution.
Any idea how to get more information about the error that occurs on the host?
Thank you very much in advance.
Generally speaking, if an error occurs in the server side code, you should call IBM support and report it. They'll ask if you're on the latest cume and probably the latest database group PTFs.
The server runs the ODBC connexion in a job called QZDASOINIT. Since there are probably many connexions to the system, there are probably many QZDASOINIT jobs. To find yours, go to a terminal session and WRKOBJLCK MYPROFILE *USRPRF. You'll be presented with a list of jobs running with your user profile. At least one of them will be the QZDASOINIT job you're looking for. Use option 5 to look at the job, then option 10 to see the job log. Press F10 to see the detailed messages and F18 to go to the bottom (most recent) entries.
If the error was so severe that the server job terminated abnormally, there won't be a lock on your user profile. Instead, go to the spooled job log by using WRKSPLF.
IBM have been logging some SQL internal errors since V5R4. select * from qrecovery.qsq901s; to see any SQLCODE -901 errors.
Make sure that you have installed the latest fix pack for the latest version of System I Access
I've had this error before and it was caused by a syntax error in the connection string. It was a setting that was insignificant in older versions of the OS and more significant in newer versions, but did not cause the connection itself to fail so it was hard to track down.
For example: Port Number:8471 had a spelling mistake and was Porte Number:8471 hard to spot but once found, it fixed the problem for me. Basically everything past this part of the connection got ignored.
Wanted to add another solution to this problem. The SQL Packages that exist on your system get corrupted after/and or during upgrades. You MUST delete these packages after an upgrade. This will get rid of the old packages and will allow the system to recreate the packages at the new OS version level. When deleting SQL packages some connections/jobs may have locks on those packages so you might have to shut host services down. Use the DLTSQLPKG command to do the delete. In v7r2 and higher there are some additional steps to do as IBM changed somethings when it comes to packages you can find the info here http://www-01.ibm.com/support/docview.wss?uid=nas8N1015556
Or tell your ODBC/JDBC/.Net Data adapter/provider to not use packages. This is probably less desirable as there are performance benefits to packages.
The MS source server technology uses an initialization file named srcsrv.ini. One of the values identifies the source server location(s), e.g.,
MYSERVER=\\machine\foobar
The docs leave much unanswered about this value. To start with, I haven't been able to find the significance of the value name, i.e., what's on the left side--and I don't see it used anywhere else. Hewardt & Pravat in Advanced Windows Debugging say "The left side ... represents the project name", but that doesn't seem to jibe with MS's "MYSERVER" example.
What is the significance of the left side? Where else is it used? Does the value reference a server or a project, and is there one per server, or one per project?
For anyone looking into this in the future, I received the following information from MS:
The name on the left side is the logical name of a version
control server. The name is also used in the source-indexed symbol files
(pdb). For example, a symbol file may contain this string value: MYSERVER=mymachine1.sys-mygroup.corp.microsoft.com:2003and the source files are referenced like this in pdb: *MYSERVER*/base/myfolder/mycode.cWhen SrcSrv starts, it looks at Srcsrv.ini for values; these values override the information contained in the .pdb file: "MYSERVER=mymachine.sys-mygroup.corp.microsoft.com:1666" overrides
"MYSERVER=mymachine1.sys-mygroup.corp.microsoft.com:2003"This enables users to configure a debugger to use an alternative source control server at debug time. The info is documented at http://msdn.microsoft.com/en-us/library/ms680641.aspx.
So, it is a logical name for a source server, and its value can be changed at debug time to reference a different server than the one originally used when the PDBs were created.
The way the debugger retrieves your source is by srcsrv using some command line utility. The utility program itself and the command line used varies depending on which type of repository hosts your code. One of the issues preventing retrieval is that when that command line program is invoked it fails.
To find out why use the command !sym noisy in WinDBG. It is mostly helpful in diagnosing symbol server issues but for source indexed PDB it also will show the actual command line WinDBG used. Copy the command from the command log window and run it in CMD.EXE to get more details on the failure.