This file is automatically generated only if you use ODBC connectivity.
--
Regards, R. J. David Burke
Centura Software Corporation
Dan Qiu <Dan...@informatik.med.uni-giessen.de> wrote in article
<36677E...@informatik.med.uni-giessen.de>...
> Hello,
>
> Some people have talked about the file GUPTA.INI, but there is no such
> file in our installation of CTD 1.5. Is this file still current and
> required?
>
> regards,
>
> Dan
>
The gupta.ini file is only needed for applications that use Centura's
SQLRouter/ODBC for connections to ODBC data sources. It is not needed for
things like VB, Delphi, etc. to access SQLBase through ODBC.
--
Regards, R. J. David Burke
Centura Software Corporation
Dan Qiu <Dan...@informatik.med.uni-giessen.de> wrote in article
<366889...@informatik.med.uni-giessen.de>...
> David Burke [Centura] wrote:
> >
> > Dan,
> >
> > This file is automatically generated only if you use ODBC connectivity.
> >
> > --
> > Regards, R. J. David Burke
> > Centura Software Corporation
> >
> > Dan Qiu <Dan...@informatik.med.uni-giessen.de> wrote in article
> > <36677E...@informatik.med.uni-giessen.de>...
> Hi David,
>
> Thank you for your answer! Is this file also required if the SQLBase
> 32-bit ODBC driver from INTERSOLV (C2GUP12.DLL) is used to access
> SQLBase databases within a client written in VB, VC++ or other
> language? I have tried all the time to get connected to our SQLBase
> database through this ODBC, but it didn't succeed. I haven't ever seen a
> file named GUPTA.INI created anywhere on my computer. To test the
> connection, I use the Tandem ODBC Test. This program functions well
> with ODBC driver for Tandem Non Stop SQL. The installation and
> configuation of the ODBC driver for SQLBase seem to be so simple. What
> could be wrong? I have only one and only SQL.INI and no installation of
> SQLBase/CDT-components of versions earlier than 7.0.1/1.5 on the
> computer(NT workstation 4.0).
>
> regards,
>
> Dan
>
In a deployment situation, I believe gupta.ini is created in the Windows
directory.
--
Regards, R. J. David Burke
Centura Software Corporation
Jarmo Muukka <jarmo....@helsoft.fi> wrote in article
<747st6$q6...@horizon.centurasoft.com>...
> I looked GUPTA.INI and I have some idea. Why there is a file GUPTA.INI?.
>
> Another questions. Is GUPTA.INI created on the same directory where the
> application is running? If so, what happens when client does not have
access
> rights to write to that shared directory on a server?
>
> --
> JMu
>
> David Burke [Centura] wrote in message
> <01be1f13$7aec51a0$7675...@DBurke.CenturaSoft.com>...
>> I have tried all the time to get connected to our SQLBase
>>database through this ODBC, but it didn't succeed.
What kind of error msg do you get other than "didn't succeed" ?
Is SQLNGCI.DLL & SQLWNTM.DLL in the path ?
>> I have only one and only SQL.INI
If you can connect with SQLTalk32 then no special entries in SQL.INI
are needed to get it to work whilst trying to connect from a non
Centura tool.
Regards,
Carsten B. Nielsen
[TeamAssist], email: iss...@image.dk
Thank you for you message! Both SQLNGCI.DLL and SQLWNTM.DLL are
abailable
in the directory CENTURA. There are no other copies of these DLLs
anywhere else on my workstation. In addition, I have checked the DLLs
called both directly and indirectly by the SQLBase 32-bit ODBC driver
C2GUP12.DLL. They are all available. As described in an earlier message,
this driver had functioned until the deploy15.exe was executed. Since
then, the ODBC driver doesn't work, and in the SQL Talk Interactive SQL,
I can connect to the SQLBase database and do database manipulations ONLY
AFTER having executed the SET SERVER .... I have downloaded all the PTFs
for CTD 1.5 and installed them, but it doesn't help. Maybe, the ODBC
driver would work again if someone could tell me how to get rid of the
SET SERVER ... before the CONNECT. Can someone from CENTURA explain and
help?
best regards,
Dan
Here is what's needed to get SQLTalk up running *before* connect:
SQLTALK.EXE,
SQLTNE.DLL ,
TLKC32.DLL ,
CSFEDT32.DLL,
DAEMON32.EXE
Do all this *loaded* components have a the same version & builld
number as your DBNT*SV.EXE ?
Thank you very much! I have completely deinstalled both the SQLBase
7.0.1 clients(We use SQLBase 7.0.1 for Netware 3.12) and CTD 1.5 today.
After having done this, I installed the SQLBase clients again. In order
to connect to and access the database, I still have to execute SET
SERVER ... at first. The product version and build number of the
components listed by you are als follows:
SQLTALK.EXE : 7.0.1 build 11915
SQLTNE.DLL : 7.0.1 build 11913
TLKC32.DLL : 7.0.1 build 11915
CSFEDT32.DLL: 7.0.1 build 11915
DAEMON32.EXE: 6.1.0
What could be wrong? All these come from the original Centura CD.
regards,
Dan
>>SQLTALK.EXE : 7.0.1 build 11915
>>SQLTNE.DLL : 7.0.1 build 11913
>>TLKC32.DLL : 7.0.1 build 11915
>>CSFEDT32.DLL: 7.0.1 build 11915
>>DAEMON32.EXE: 6.1.0
>>What could be wrong?
Looking a little closer today I find that I use the same ver & build
as you and I have to wonder if SQLTNE.DLL exist as build 11915. I dont
know much about DAEMON32.EXE other that SQLTalk will 'ups' if it is
not there. My DBNT1SV.EXE, SQLWNTM.DLL, SQLNGCI.DLL are build 11913
too. One probably need to be part of the SB team to use this build no.
to something usefull.
Since you use CTD this will install a SB Desktop Single user, do you
need to SET SERVER if you try connect to that one too ?
Some versions ago SQLtalk set up ref to \Program Files\Common
Files\Centura, is any sign of that left in the registry ? Any Files
there ?
Do you have another computer ? Install there and get the bug twice !
Do you ?
David Burke [Centura] wrote:
> The gupta.ini file is created so that ODBC DSNs (which can be longer than 8
> characters and have spaces) can be mapped to 8 character strings that the
> SQL/API can handle.
>
> In a deployment situation, I believe gupta.ini is created in the Windows
> directory.
>
> --
> Regards, R. J. David Burke
> Centura Software Corporation
>
> Jarmo Muukka <jarmo....@helsoft.fi> wrote in article
> <747st6$q6...@horizon.centurasoft.com>...
> > I looked GUPTA.INI and I have some idea. Why there is a file GUPTA.INI?.
> >
> > Another questions. Is GUPTA.INI created on the same directory where the
> > application is running? If so, what happens when client does not have
> access
> > rights to write to that shared directory on a server?
> >
> > --
> > JMu
> >
> > David Burke [Centura] wrote in message
> > <01be1f13$7aec51a0$7675...@DBurke.CenturaSoft.com>...
> > >Dan,
> > >
> > >This file is automatically generated only if you use ODBC connectivity.
> >
> >
> >
A small clarification to my Well Esteemed colleagues reply. In CTD, the
gupta.ini is created in the same location as the cdlliXX.dll.
charlie
--
Charles McLouth
Centura Software Corp. http://www.centurasoft.com
Premium Enterprise Support Team http://www.centurasoft.com/support/
Senior Support Engineer mailto:charles...@centurasoft.com
Dan Qiu wrote:
> Carsten B. Nielsen[TAO] wrote:
> >
> > Dan ,
> >
> > >> I have tried all the time to get connected to our SQLBase
> > >>database through this ODBC, but it didn't succeed.
> >
> > What kind of error msg do you get other than "didn't succeed" ?
> >
> > Is SQLNGCI.DLL & SQLWNTM.DLL in the path ?
> >
> > >> I have only one and only SQL.INI
> >
> > If you can connect with SQLTalk32 then no special entries in SQL.INI
> > are needed to get it to work whilst trying to connect from a non
> > Centura tool.
> >
> > Regards,
> >
> > Carsten B. Nielsen
> > [TeamAssist], email: iss...@image.dk
> Hi Carsten,
>
> Thank you for you message! Both SQLNGCI.DLL and SQLWNTM.DLL are
> abailable
> in the directory CENTURA. There are no other copies of these DLLs
> anywhere else on my workstation. In addition, I have checked the DLLs
> called both directly and indirectly by the SQLBase 32-bit ODBC driver
> C2GUP12.DLL. They are all available. As described in an earlier message,
> this driver had functioned until the deploy15.exe was executed. Since
> then, the ODBC driver doesn't work, and in the SQL Talk Interactive SQL,
> I can connect to the SQLBase database and do database manipulations ONLY
> AFTER having executed the SET SERVER .... I have downloaded all the PTFs
> for CTD 1.5 and installed them, but it doesn't help. Maybe, the ODBC
> driver would work again if someone could tell me how to get rid of the
> SET SERVER ... before the CONNECT. Can someone from CENTURA explain and
> help?
>
> best regards,
>
> Dan
What are the versions of the sqlwntm.dll & sqlngci.dll?
--
JMu
Charles McLouth wrote in message <366DADB0...@centurasoft.com>...
I mad one temporary application which copies data from two databases to
third database. When user run the app and queried, it showed SQL-error
saying there is invalid column name. This was odd because there is column
with that name.
I edited manually their GUPTA.INI-file and asked user to stop and start the
app. Now the query worked fine.
Answer is that if user does not have write access to GUPTA.INI-file, it
ignores the write operation errors and connects to wrong database.
--
JMu
Jarmo Muukka wrote in message <74qgf8$kn...@horizon.centurasoft.com>...
Centura -
Either make this file REALLY functional or remove it from the application.
There are too many problems such as these to justify it's existence. Connecting
to the wrong database is as useful as not connecting at all and a whole lot more
dangerous!!!
Just one of my favorite pet peeves!!
__Sue