You are viewing limited content. For full access, please sign in.

Discussion

Discussion

Forms-External Table lookup SQL Timeout

posted on February 22, 2022

Hello,

We have a customer with a strange issue with regards to a Forms Email activity the is pulling email addresses from an External Table.

Occasionally Forms instances will suspend (not all of them though) at the Email activity and the corresponding error in the logfile is as follows: 

"A network-related or instance-specific error occurred while establishing a connection to SQL Server. The server was not found or was not accessible. Verify that the instance name is correct and that SQL Server is configured to allow remote connections"

If we retry this instances, some a few times, they will move on.

In the Forms Config I checked the DB connection and it is using the SA account, which a SysAdmin and DBO for the External Table.

We can ping the SQL server from Forms.

If we query the External Table from the Admin console and SMSS it returns the same number of rows.

SQL is set to use Mix Mode and we have bounced the service and server a few times, but this issue still persists.

Not sure where else to look on this as not every instances is suspended at this activity.

Appreciate the feedback,

Jeff Curtis

 

0 0
replied on February 22, 2022

Hi Jeff,

This sounds like intermittent connectivity issues from the Forms server to the SQL instance. That it only happens occasionally, and that retrying the instance task reliably once to a few times reliably works, would substantiate this. If it's not happening often and only for short time spans, you're unlikely to catch it with assorted spot checks. 

Set up continuous network monitoring between the Forms instance and the SQL instance. Make sure you're specifically checking traffic/connectivity on TCP port 1433 (or your custom SQL port) and not with ICMP ping checks.

If you do need to spot connectivity check from the Forms server, use SSMS or the following PowerShell command:

Test-NetConnection sqlServerFQDN -port 1433

As a security best practice, please do not use the SQL "sa" account for Laserfiche SQL connection profiles to any data source. Create a separate account that has only the "public" server-level role, the "db_owner" database-level role on the database(s) it needs schema modification rights to (e.g., application databases), and "db_reader" (plus "db_writer" if necessary) on supplemental lookup DBs/tables like the one you're describing here.

Cheers,
Sam

1 0
replied on February 23, 2022

Thanks Sam,

I will follow up with their IT.

Jeff

0 0
replied on February 28, 2022

Hey Sam,

So when we run the PS command from the Forms Server pointing to SQL Ping and TCP are successful.

When we run the PS command from the SQL server pointing to the Forms server, Ping is successful, but TCP shows as False.

We are working on getting network monitoring tool in place.  They are thinking of using Wireshark. I think that is the best free tool I know of.

Give TCP fails on the SQL server could this be the possible culprit?

Thanks,

Jeff Curtis

0 0
replied on February 28, 2022

Hey Jeff,

TCP connections are directional and "stateful". What matters is that the direction the connection is initiated in (Forms -> SQL) is open on the desired port. SQL Server never initiates a connection to Forms, so the SQL -> Forms path isn't relevant from a firewall perspective.

Wireshark is good. Make sure you put in "capture filters" that restrict the packet captures to TCP traffic on port 1433 with a destination of the SQL Server's IP address. I don't recall the exact syntax offhand but it's an easy Google.

 

0 0
replied on February 22, 2022

Personally, I would log a support ticket with Laserfiche.

However, are they using SQL Express?

0 0
replied on February 23, 2022

Hello Jonathan,

Using Full SQL

Jeff

0 0
You are not allowed to follow up in this post.

Sign in to reply to this post.