ADSDBE 1.9 can't connect to the ADS Sever using a drive letter as previous version.

Christian Laborde
True E-mail : remove dash and no spam
Rte de la Conversion, 20
CH 1095 Lutry
Suisse

Christian,

> ADSDBE 1.9 can't connect to the ADS Sever using a drive letter as previous
version.

I have no problem like that, you should probably provide some code:

DacSession():New("DBE=ADSDBE;SERVER=H:\Trasys\database")
Or
DacSession():New("ADSDBE", "H:\Trasys\database")

Both work, in my case, using 1.9
NB. the second one is for compatibility only, but works just the same.

Regards,
Frans Vermeulen

Hello Christian,

> ADSDBE 1.9 can't connect to the ADS Sever using a drive letter as
> previous version.

ADSDBE 1.9 connects fine, but ACE32 must be able to resolve the drive letter 
to the actual server hosting ADS.

Five potential problems:

A) If you use Distributed File System (DFS) to map your drive letters, ACE32 
cannot discover the actual server.
B) If you run your application under another user session (RUNAS or as a 
Service), drive mappings are not necessarily the same as the foreground user 
session.
C) Settings in your ADS.INI file can define drive letters for ACE32 that 
supercede your actual drive mappings.
D) Even if ACE32 can discover the actual server, IP communications between 
the client and server on the ADS server port (6262) can be blocked by a firewall.
E) If ADS is configured to use semaphore files to maintain client connection, 
the client must have access to the semaphore share.

After connection, an additional problem opening tables in proprietary mode:

A) On older versions (pre 8.x) of ADS, two clients opening the same table 
using different filename paths were not recognized as the same table.  The 
second user could be blocked.

You can use the ARC tool included with ADS to test connectivity independent 
of ADSDBE.

Once you solve your problem, I would be curious to know which it was.

Regards,

Rodd Graham, Consultant
Graham Automation Systems, LLC

Rodd Graham a écrit :
> Hello Christian,
> 
>> ADSDBE 1.9 can't connect to the ADS Sever using a drive letter as
>> previous version.
> 
> ADSDBE 1.9 connects fine, but ACE32 must be able to resolve the drive 
> letter to the actual server hosting ADS.
> 
> Five potential problems:
> 
> A) If you use Distributed File System (DFS) to map your drive letters, 
> ACE32 cannot discover the actual server.
> B) If you run your application under another user session (RUNAS or as a 
> Service), drive mappings are not necessarily the same as the foreground 
> user session.
> C) Settings in your ADS.INI file can define drive letters for ACE32 that 
> supercede your actual drive mappings.
> D) Even if ACE32 can discover the actual server, IP communications 
> between the client and server on the ADS server port (6262) can be 
> blocked by a firewall.
> E) If ADS is configured to use semaphore files to maintain client 
> connection, the client must have access to the semaphore share.
> 
> After connection, an additional problem opening tables in proprietary mode:
> 
> A) On older versions (pre 8.x) of ADS, two clients opening the same 
> table using different filename paths were not recognized as the same 
> table.  The second user could be blocked.
> 
> You can use the ARC tool included with ADS to test connectivity 
> independent of ADSDBE.
> 
> Once you solve your problem, I would be curious to know which it was.
> 
> Regards,
> 
> Rodd Graham, Consultant
> Graham Automation Systems, LLC
> 
> 
1) I have this problem since I migrate to 1.9
2) ads.ini is always the same and ARC has no problem to discover ADS server.
3) I can connect with IP not with drive letter

Regards

Christian Laborde
True E-mail : remove dash and no spam
Rte de la Conversion, 20
CH 1095 Lutry
Suisse

Rodd Graham a écrit :
> Hello Christian,
> 
>> ADSDBE 1.9 can't connect to the ADS Sever using a drive letter as
>> previous version.
> 
> ADSDBE 1.9 connects fine, but ACE32 must be able to resolve the drive 
> letter to the actual server hosting ADS.
> 
> Five potential problems:
> 
> A) If you use Distributed File System (DFS) to map your drive letters, 
> ACE32 cannot discover the actual server.
> B) If you run your application under another user session (RUNAS or as a 
> Service), drive mappings are not necessarily the same as the foreground 
> user session.
> C) Settings in your ADS.INI file can define drive letters for ACE32 that 
> supercede your actual drive mappings.
> D) Even if ACE32 can discover the actual server, IP communications 
> between the client and server on the ADS server port (6262) can be 
> blocked by a firewall.
> E) If ADS is configured to use semaphore files to maintain client 
> connection, the client must have access to the semaphore share.
> 
> After connection, an additional problem opening tables in proprietary mode:
> 
> A) On older versions (pre 8.x) of ADS, two clients opening the same 
> table using different filename paths were not recognized as the same 
> table.  The second user could be blocked.
> 
> You can use the ARC tool included with ADS to test connectivity 
> independent of ADSDBE.
> 
> Once you solve your problem, I would be curious to know which it was.
> 
> Regards,
> 
> Rodd Graham, Consultant
> Graham Automation Systems, LLC
> 
> 
ARC use ads.ini in Windows directory. ADSDBE use first ads.ini in exe directory. 
  This one was bad in my case. So I remove it and problem is solved.

Regards.

Christian Laborde
True E-mail : remove dash and no spam
Rte de la Conversion, 20
CH 1095 Lutry
Suisse

Hello Christian,

> ARC use ads.ini in Windows directory. ADSDBE use first ads.ini in exe
> directory.
> This one was bad in my case. So I remove it and problem is solved.

Good to hear you found the problem.  

FWIW, the ACE32.dll library is what uses the ADS.INI configuration file, 
not ARC or ADSDBE.  ACE32 will try to open the file from the same folder 
the dll is located in before using the system search path.  

To remove ambiguity and ensure that my applications always run with the correct 
ADS.INI, I always put ACE32.DLL and ADS.INI (and ADSLOC32.DLL) in with my 
Xbase++ runtime.  I then manage the Xbase++ specific ADS.INI from the Xbase++ 
application.  Of course this does mean that my Xbase++ applications use a 
different ADS.INI than the ARC tool, but I don't rely on sharing settings 
between the two.

Regards,

Rodd Graham, Consultant
Graham Automation Systems, LLC