I downloaded TD 5.2 test drive and after upgrading my App from 2.1 to 5.2 I'm trying to connect to an oracle DB an error appears when connecting
as follow "DBMS not available:3729 SQL Error 3729 Not Found in Error.SQL file
Find the attached Sql.ini
do you have a SQLBASE - environmentvariable ? it schould point to the new installed TD Folder (where your sql.ini is)
Or you can set in sql.ini clientruntimedir="<Path to new TD installation>"
00134 SQL CNO ERROR.SQL NOT FOUND LOOKING UP ERROR 03729
I need help it's a top urgent
Error # 134:
00134 SQL CNO Could not open file 'error.sql'
Reason: SQLBase is trying to open the file ERROR.SQL but can't find it.
Remedy: Verify that ERROR.SQL is in either your current directory, the \SQLBASE subdirectory under the root directory, in the root directory, or in a directory specified by the PATH environment variable.
Error # 3729:
03729 CFF PEX Cannot open SQL.INI configuration file for read or write
Reason: The SQL.INI file could not be opened for read or write. Either the file doesn't exist or it is locked by another program which may be writing to the file or has no read/write privilege.
Remedy: Make sure you do have a SQL.INI file. Check the SQL.INI configuration file attribute.
In regional and language setting in Advanced tab I use Arabic(Egypt) as a language for non unicode programs
when I change it to English and restart I'm able to connect through the application and through SqlTalk
Can this issue be solved or not because all my customers use this seeting
we now ran into the same problem!!!!
Rolling out our software in Egypt, we have the same connection-problems!!!
The metioned setting for "non unicode applications" to "Arabic (Egypt)" is very important for our customers.
But we can't get a connect with our application (on TD5.2-SP2-Build21679 and TD6.0-SP1-Build23971M).
Setting: I traced the activities of the sample (attached) on connecting with the "ProcessMonitor" (from Microsoft's "SysInternals"): Be aware of the "special" filename, that is created!!!
Seems to me, that this tries to open the "sql.ini", but creates this mystical filename ...
See attached my sample, and 2 screenshots (one with the connection ok on "german"-setting, the other with the error on "arabic"-setting)
Please take a close look at this and find a solution, as we are CURRENTLY ROLLING OUT OUR APPLICATION TO OUR CUSTOMERS!!!
This is really urgent for us!!!
Cheers from Vienna,
Sorry for the delay and yes you are right the Arabic ( Egypt) locale indeed causes a problem. At first I notice you sql.ini
and though it could be related to the use of @TNS:
please use instead directly this instead
This will not fix your issue though just an advice, it is supposed to provide better performance when connecting.
So indeed could reproduce the problem by simply switch my locale and reboot and only launching SQLTALK.EXE from explorer would fail with same error
In the sanpshot 2 oracle instance connected : UNICODE and WIN1252
Connection failure error 03729 when using Arabic (Egypt) locale
as stated probably against all DB BRAND when using SQLBASEAPI.
-tested on ORACLE 11g SEVEN with LOCAL set to Arabic (Egypt) locale and TD 6.0 LAST VERSION
-once you setup the environment just execute SQLTALK.EXE from the explorer would return right away error 03729
Same problem with 5.2
is there a plan on how and how fast this will be fixed?
We NEED this for new customers URGENTLY!!!!
I'm still having the problem do you find out a solution
we have the same problem as you: login to our oracle database is impossible in arabic.
This is a very serious problem for us because most of our clients uses Arabic.
We just report this bug and have little time to fix it.
After search on the forum, and have asked for a TD expert, it seems to be a bug with no solution for the moment.
If you have one, do not hesitate to communicate!
For our part, we find a workaround solution wich is the following one:
We noticed that this problem is related to the connector Centura ODBC or sqlora (sql.ini). We do no longer use sql.ini, but connecting via oledb.
Indeed the issue shows on TD 6.x version the same way as it used to show on the 5.2 version at the time with TD-15145.
This bug is FIXED on TD 5.2 SP4, I verified it but indeed did not seems to make its way on 6.x version.
I will advice the US on the issue...
So TD-15145 is currently OPEN for 6.x
Who is online
Users browsing this forum: [Ccbot] and 0 guests