Conexão ao servidor do banco de dados via internet

Ah sim! Desta forma também funciona. Era como estava sendo feito inicialmente. Agora existe a necessidade de ser local mesmo.

waxxyy, só cuidado com o parâmetro -n, em questão do licenciamento. Se você aumentar muito além da quantidade de licenças que você tem.

Achei isso aqui no KB:
Cause
Error 748 means that an attempt was made to exceed the limit for the number of users making a connection to the database.

Error 1334, means that either the limit of the servers spawned (Mn), or the limits imposed by the specific client environment setup have been reached, so a new server cannot be spawned for new client connection(s).
Resolution
1) The number of remote clients is limited by the lesser of: -n and the product of multiplying -Mn and -Ma. Check the settings of these parameters against the client connection requirements and the license agreement.

2) promon -> R&D (1: Status Displays, 3: Services). Make sure all the ports in the range from -minport to -maxport or the default ports used by Progress are free for connection and are not being blocked for any network device or ports communication software. Progress recommends a minport > 2000, as these are usually the ports reserved for O/S processes.

3) One explanation, specific to this particular environment, is that you could be hitting a limitation on SCO OpenServer relative to the number of TCP connections that can be made to that machine. The install default is 256.

4) In addition to checking the Services | Host files (outlined in P2916, "Corrective Measures for Error 748"), if the clients are using .pf files to connect, it is worth verifying that:

A) The content of these are correct. Uppercase and lowercase entries are the usual culprits.

B) The location of these are correct, particularly when using mapped drives.5) The machine that the Progress server is running on may have run out of processes or semaphores. In this case it may be possible to reconfigure the machine to provide more processes at a time and to provide more semaphores.

The size of the connection table could be the value being called into question:

usrtbl = the number of users (-n), + the number of servers (-Mn), + one(1) reserved for proshut.
Whatever size is computed for the connection table (usrtbl), that is the number of semaphores needed -- one per connection.

The kernel settings for number of processes that can run at a time, and number of semaphores provided should be examined. The change to support multiple semaphore sets in Version 8.3 and later, may be causing the system to behave differently. P2916 explains these in more detail, initial recommendations are:

Total number of semaphores allowed for the system [SEMMNS] (=10872?)
Max. number of semaphores allowed per semaphore identifier [SEMMSL] (=453?), SEMMNU (=SEMMNS)
The maximum size of a single shared memory segment [SHMAX] (=128MB)
6) Check that the correct progress.cfg is being used​

Sim, eu tbm fiz isso @bootstrapmaster , aqui utilizamos RBs para ligar a VPN, e olha dificilmente cai.

Obrigado pelas respostas!

Descobri que o problema inicial estava ocorrendo por alguma interneferencia na rede interna da Loja 1, e nada tinha a ver com a conexão via internet como eu imaginava inicialmente.

Utilizar o MSTSC da maneira que colocaram é uma boa alternativa. Anteriormente testamos com ele mas os usuarios acharam 'complicado', eles queriam clicar no icone e ir para o sistema de uma vez, sem ter que acessar o terminal MSTSC antes disso. Frescuras. Outra dificuldade é que outro pessoal cuida do gerenciamento do servidor, entao pra criar os usuarios e arrumar algum eventual problema no servidor era necessário entrar em contato com eles primeiro, coisa que muitas vezes me 'amarrava' na agilidade da solução de alguns problemas.

mas isso são pormenores facilmente solucionáveis.

Vou testar mais um pouco utilizando a internet para ver como se comporta mas deixarei a solução sugerida por voces preparada!

Mais uma vez obrigado pela atencção!