To access network files from a machine where a PSQL application is running, you must use an appropriate client requester on that machine. PSQL calls made by your application go through the client requester, which sends them to the server and then passes the reply to your application.

Generally, the default property settings for PSQL server and its clients are sufficient to enable them to communicate and function correctly. You typically do not have to change any properties, but if other settings are needed, they are covered in the following topics:

This topic lists the configuration settings used by the PSQL Client for network communication. These settings may be changed using a command line utility or from within PCC on the engine properties.

The Advanced Operations Guide provides detailed information about each of the settings. See the following configuration settings in Advanced Operations Guide for network communication:

When using your Requester, you connect to the PSQL Server engine to access data files. This section shows the variations on network file syntax you can use to access files on your network using Btrieve or DTI applications.

PSQL supports the Universal Naming Convention (UNC) and Drive path formats (explicit and current) across the majority of operating environments.

For more information on the path formats, see the sections that follow:

If you are an application developer, also note that the certain access methods, such as the Btrieve API, support URI connection strings. For details about URI strings, see Database URIs in PSQL Programmer's Guide. In Btrieve API Guide, see Create (14), Open (0), and Login/Logout (78).

The following UNC path formats are supported on all clients to all servers:

\\ServerName or IP address\share\path\file

\\ServerName or IP address\share:[\]path\file

UNC syntax is resolved correctly regardless of the actual type of network operating system (NOS) running on the target server. If you use an IP address, it must be a dotted IPv4 address or one of the two formats supported for IPv6. See IPv6 Addresses.

The following drive representations are supported on all clients to all servers:

drive:file
drive:[\]path\file
file
[\]path\file
..\file

Incoming paths on a Linux, macOS, or Raspbian server using Samba are processed as follows in order of relative priority:

\\server\sharename\path

The smb.conf file must be configured to accept the share name, or otherwise it will default to an absolute path as described in the next topic.

\\server\absolute_path

If the smb.conf file is not configured properly or not found on the target server, the absolute path is used.

For more information on the Linux, macOS, and Raspbian editions of PSQL, see Using PSQL on Linux, macOS, and Raspbian.

On macOS servers, third-party packages are not the only way to enable Samba sharing. macOS supports native SMB-style sharing without a smb.conf file. Use System Preferences > Sharing or the sharing command to configure a share or view existing shares.

A PSQL Client using any of the access methods supported by PSQL connects using IPv6 to an IPv6 host running the PSQL database engine the same way as it does for IPv4. That is, the client specifies a server and connects through one of the supported access methods. The server can be either the name or IP address of the machine running PSQL Server or Workgroup.

All of the PSQL access methods except for ActiveX support IPv6 connections. Some access methods are Windows only, but can be used with a client-server combination of Windows and Linux, macOS, or Raspbian.

This topic addresses the following aspects of IPv6:

Raw IPv6 addresses can be written as 8 colon-separated segments where each segment is a 4-digit hexadecimal value. For example, 1234:5678:90ab:cdef:1234:5678:90ab:cdef. Within this framework, several forms of IPv6 names are possible.

In general, numeric IPv6 addresses are more complex and difficult to manipulate than IPv4 addresses. Numeric Link Local addresses are notably problematic, especially with regard to Zone IDs.

For that reason, we recommend the use of host names through DNS servers, LLMNR, host files, or other means of address resolution, particularly for production environments. PSQL support for numeric IPv6 addresses is intended mainly for development environments. Because many contexts require square brackets for IPv6 numeric addresses, when in doubt, add them if numeric addresses are necessary.

PSQL supports only unicast addresses. The following are the unicast address formats that can be used with PSQL.

IPv6 includes address modifiers that can act as shortcuts or can specify the destination in more detail. PSQL supports the following ones for IPv6.

PSQL supports IPv6-literal.net names on Windows and bracketed IPv6 addresses on Windows, Linux, macOS, and Raspbian.

An ipv6-literal.net name is a raw IPv6 address with three changes:

Examples

A bracketed IPv6 address is a raw IPv6 address with square brackets around it. This format is also referred to as a Uniform Naming Convention (UNC)-safe address.

Examples:

The following table lists the restrictions on the use of IPv6 with the MicroKernel Engine.

The inclusion of a port number with an IP address is necessary only when you need to override the default port. Generally, a port number can be appended to an IP address using either a colon (:port number) or a dot (.port number).

UNC-safe names (see Address Presentations) support the appending of a port number.

All of the previous topics about IPv6 apply to Linux, macOS, and Raspbian distributions, with specifics noted. The following topics discuss additional aspects of IPv6 when used with Linux, macOS, and Raspbian.

Full IPv6 support is a relatively recent feature of operating systems. For this reason, we recommend that you use the most current Linux, macOS, or Raspbian distribution. See the Actian website for a list of the Linux, macOS, and Raspbian distributions and use the most current distribution of the latest one listed.

Note the following limitations and conditions when you use IPv6 with Linux, macOS, or Raspbian:

We recommend the following practice when you use IPv6 with Linux, macOS, or Raspbian.

Use pvnetpass to ensure that the PSQL Client platform provides the required credentials on a server when the client connects to the database engine on that server. Pvnetpass is required for each different server address connection, even equivalent server addresses. For example, suppose that a host name and an IPv6 numeric address refer to the same server. A connection to each one requires the use of pvnetpass. See pvnetpass in PSQL User's Guide.

The following table answers some frequently asked questions about IPv6 support and PSQL.

This section documents the use of TCP/IP when connecting to a PSQL server running on a Windows server platform.

When PSQL operates in a TCP/IP network, your client must be able to obtain the IP address of your Windows server from the name given to that server. There are two mechanisms that enable this address-to-name translation:

The following procedures provide an overview for how to set up the IP address using each method. For details about network configuration and set up, refer to the documentation for the operating system.

When you use DNS, you specify settings that allow your computer to look up the address of the server in a database of servers. Your network administrator can provide the information you need to configure DNS.

The hosts file is a way to manually enter a relationship between a name and an IP address. Use this method if DNS is not used in your organization.

Depending on the settings for your browser, the Windows Dial-Up Networking dialog box can display when a TCP/IP request is made. Usually, this is to make an Internet connection, but this feature can be an annoyance when using PSQL applications and TCP/IP.

This section documents the use of SPX when connecting to a PSQL server running on a Windows machine.

SPX is not a native protocol on the Windows platforms. If you want to use SPX, perform the following procedures to ensure proper operation with PSQL.

If you have both TCP/IP and SPX installed, you must remove TCP/IP from the PSQL Client configuration to make SPX function with PSQL applications

PSQL communicates through three ports. Your firewalls and routers need to allow access to the following ports for remote access with the Server database engine:

Typically, you do not need to modify the ports unless you have a conflict with them.

For the Relational Engine, port assignment 1583 is configurable on the server through the PSQL utilities. This port is manually configurable for clients. See TCP/IP Port in Advanced Operations Guide.

We recommend that port assignment 3351 not be changed. If you must change it, contact Technical Support.

Ensure that the port configurations match on both the server machine and all clients.

After changing your server listening port, you must stop and restart your database engine for the port assignment changes to take effect. See Using PSQL in PSQL User's Guide.

The services file is a text file used by the operating system for network communications. In the services files, you can manually assign the ports used by PSQL Server and its clients. Be sure that the applicable ports listed in the services file are in agreement with the ports set by PSQL in the utilities and with the associated Windows Firewall rules.

After changing port assignments in the services file, you must stop then start the PSQL database engine for the changes to take effect.See Starting and Stopping the Database Engine in PSQL User's Guide.

The installation of PSQL Server and PSQL Workstation performs certain actions pertaining to firewalls. Starting with Vista, Windows operating systems include Windows Firewall with Advanced Security, which provides firewall profiles (a group of security settings). These operating system enable the firewall by default. The following table summarizes the PSQL installation actions pertaining to the active profile(s).

As the table shows, if the Public profile is active with one or more other active profiles, the PSQL rules are added for the Public profile but disabled. Neither the interactive nor the silent installation of PSQL Server or Workgroup can be modified to change this behavior. If you want to enable the rules for the Public profile, you must do so manually. See To enable PSQL rules for the Public profile.

If you change a network profile after installation of PSQL, PSQL may no longer be able to accept communications. For example, assume that only the Private network profile was active during installation. At some point after installation, the active profile is changed to Domain (assume its settings are very different from those of Private). The database engine will no longer be able to communicate across the network.

If you change profiles or firewall rules in a way that prevents PSQL communications, refer to the steps in To enable PSQL rules for the Public profile. Use the steps as a general guideline for how to enable the PSQL rules for the active profile(s). This will allow the database engine to communicate again across the network.

A corporate policy may prevent a local administrator from modifying the firewall profiles on a particular machine (that is, the profile is “locked”). If so, the PSQL installation cannot add or enable the firewall rules required for the database engine to communicate across a network connection monitored by a locked profile. For such a situation, you should contact a corporate systems administrator and request that the firewall policy be modified to allow inbound TCP and UDP traffic on all ports to communicate with all installed PSQL services.

Also be aware that a Group Policy only prevents the installation from adding and enabling rules on firewall profiles controlled by the Group Policy when the target system is joined to the domain. If the user installing PSQL is logged into the target system as a local user instead of as a domain user, the installation does add and enable the rules on the firewall profiles. However, the rules are disabled if the target system is later joined to the domain controlling the Group Policy.

Your Samba must be properly configured on your Linux, macOS, or Raspbian server to network with Windows-based clients when using mapped drives.

When PSQL operates in a TCP/IP network, your client must be able to obtain the IP address of your Linux, macOS, or Raspbian server from the name given to that server. Two mechanisms enable this translation of address to name:

The following procedures provide an overview for how to set up the IP address using each method. For details about network configuration and set up, see the documentation for the operating system.

When you use DNS, you specify settings that allow your computer to look up the address of the server in a database of servers. Your network administrator can provide the information you need to configure DNS.

For clients on Windows platforms:

The hosts file is a way to manually enter a relationship between a name and an IP address. Use this method if DNS is not used in your organization.

The Windows Dial-Up Networking dialog box can open when a TCP/IP request is made to Windows. Usually, this is to make an Internet connection, but this feature can be an annoyance when you are using PSQL applications and TCP/IP.

The use of encoding methods is intended for advanced users. In general, the default encoding settings are sufficient and do not require changing. See Database Code Page and Client Encoding in Advanced Operations Guide.

PSQL supports DOS Btrieve applications with the DOS Requester. The DOS requester supports Btrieve applications only, not ODBC applications. This section explains how to use the DOS requester to run PSQL-based DOS applications in Windows.

DOS Box support allows a DOS application to run in a DOS box on a Windows platform. This enables direct communication to the Windows 32-bit workstation components rather than to the database engine. This configuration can be used with either a local PSQL Workgroup engine, or a remote engine. The TCP/IP, SPX, or NetBIOS protocol supported for client-server access depends on the configuration of the Windows 32-bit components.

The DOS requester supports both Workgroup and Client to remote Server engine configurations.

The Requester for Windows is BTRBOX. You can use this Requester for DOS applications.

All of the components needed to run DOS applications using BTRBOX are installed with your client. After the Windows client component installation, you have everything you need to run a DOS or Windows 32-bit application. The default DOS application support installed is the Win32 DOS Box configuration.

DOS applications are not supported on 64-bit Windows platforms. Therefore, BTRBOX is not supported on 64-bit Windows platforms.

On Windows platforms, the DOS Box install configures the drivers to be completely transparent. Thus, you are able to immediately open a command prompt and run a DOS Btrieve application. The CONFIG.NT file, located in the %WINDIR%\SYSTEM32 directory, contains the command that enables DOS application support. This file is similar to CONFIG.SYS in DOS. The Windows operating system loads the driver for each DOS session opened. In the configuration file, the install places the following path to load the DOS Box driver:

DEVICE = C:\WINDOWS\SYSTEM32\BTRDRVR.SYS