Hi John, Just checking...
If you go to Apple menu, System Preferences on the mini, for Network do you see more than one green dot? Each is separate network connection, where you can click Advanced and go to TCP/IP tab for details. Is not unheard of for someone to set up Ethernet and Wi-Fi. Back in System Preferences, Energy Saver, you probably want Prevent Computer From Sleeping on all computers, but especially server. It is common for an upgrade of computer or system to reset this, to be green. That said, be aware that 16.4 used New Networking only, which allows Clients to sleep. It is possible, if you have the Compatibility checkbox (in 4D Server, File menu, Database Settings) set to Use Legacy Network Layer that this works in 17.1 and would cause the errors below if Clients did Sleep. This checkbox would have no effect (and different text) in 16.4 and Clients could Sleep and wake no problem. Maybe all you need is to uncheck this. Hope this makes sense. -Spencer On 4/24/19, 4:54 AM, "4D_Tech on behalf of John DeSoi via 4D_Tech" <[email protected] on behalf of [email protected]> wrote: Since I upgraded from 16.4 to 17.1 (all Mac), users have been complaining about 4D Client disconnects. Messages like: "The current connection to the database has been disrupted. Connection error with the server. Please restart the application." "Unknown Error. Connection error with the server. Please restart the application." It is an all local single switch network with default timeouts. I experimented with changing timeouts, but it did not help. The server hardware also changed (new 2018 Mac Mini), so I'm looking into that. One curious thing I noticed is the "Application Server" tab shows it to be listening on two IP addresses: 192.168.X.X and 169.254.X.X. The 192 address is expected and the only active network connection on the computer. Why would the server be listening on a 169 link-local address and where did that come from? I don't see that when I run the server on my laptop under the same operating system (10.14 Mojave). Digging into it with Wireshark is next, but hoping someone might suggest an easier path. John DeSoi, Ph.D. ********************************************************************** 4D Internet Users Group (4D iNUG) Archive: http://lists.4d.com/archives.html Options: https://lists.4d.com/mailman/options/4d_tech Unsub: mailto:[email protected] ********************************************************************** ********************************************************************** 4D Internet Users Group (4D iNUG) Archive: http://lists.4d.com/archives.html Options: https://lists.4d.com/mailman/options/4d_tech Unsub: mailto:[email protected] **********************************************************************
