Announcement

**Isomorphic** · 18 Feb 2020, 15:55

This log simply shows that you set up
some DB connections that aren’t working, because the DBs are just not there, not through any fault of our framework.

Then server startup completes and the Admin Console is ready to use again.

You may have tried to reload the page before the server finished restarting.

**cavogadr** · 19 Feb 2020, 06:43

How are you MAN, everything ok ???
Let's see if I understand, after thirty years in IT, I am trying to connect to a database that does not exist ??? !!!, only exists in my mind ??? !!! ... is what you You say, well, I interpret your answer.
To your knowledge, both SQLSERVER 2008 R2 and SMARTCLIENT are running on the same virtual machine. I don't know where you could deduce that the database does not exist.
Well, don't worry, I'll leave it that way, without connecting to the engine I need. For now I am using the client-side, I will populate the controls with my own web-services.

Thanks,
Carlos

**Isomorphic** · 19 Feb 2020, 10:45

We wouldn’t care to speculate as how to 30 years of IT experience led to this situation, but the log clearly shows a failure to connect. That could be bad credentials or permissions, or in troubleshooting you temporarily stopped the server, or many other things, but what we can say for a certainty is that our software is not the problem, as our code (com.isomorphic) isn’t even in the error stack trace.

**Isomorphic** · 19 Feb 2020, 11:00

BTW you seem to be saying that this log is from starting our embedded server, configuring a DB and just saving. But you've got Hibernate and Spring-related logs going on here that suggest you must have made some other changes to get this kind of error.

Also, you haven't said for what URL you get a 404. For the Admin Console? That also doesn't seem possible, given the claimed steps. You would have to have the embedded server running to receive a 404 at all. And once it is running, the only kind of error you could get, if you had somehow broken the Admin Console, would be some 5xx server error. Unless you just deleted the .jsp outright?

In a nutshell, the diagnostics you've provided here don't line up with the steps you say you took. It looks more like: you set up several things, then as the server started, you turned off networking on the VM (*shrug*).

**cavogadr** · 19 Feb 2020, 12:27

Good afternoon,
I already found the cause that causes the service to be interrupted.

When from the admin-console you want to perform any action that modifies the SERVER.PROPERTIES file, it records it incompletely, truncates it, without defining the datasources section and something the rest of configuration.
Then, of course, that is why TOMCAT throws the error.

What I did was then, unzip only the SERVER.PROPERTIES file from the package that I downloaded. I overwritten the corrupt file.
Finally, I modified that file by hand and ... Voil�!!!, everything works correctly.
I even created several datasources at different sqlserver engine.

PD: I just think you had to get a little more what I had written and we would have solved it much earlier.

Anyway

THANKS A LOT.

Regards,
Carlos

**Isomorphic** · 20 Feb 2020, 21:23

We were unable to reproduce any issue with a truncated server.properties file. However, it does look like Tomcat has recently introduced a new bug, where, on certain platforms, attempts to restart the server just fail. Nothing is wrong with the configuration and again, nothing truncated, but Tomcat does manage to wedge itself, requiring a restart.

We're looking into how to work around this new Tomcat bug. In the meantime, if you use the Admin Console to save a new properties file, just manually restart Tomcat.

Note also that there is comprehensive documentation on directly setting SQL settings if you need them.

**Isomorphic** · 26 Feb 2020, 13:37

Just to confirm - it wasn’t Tomcat per se but some other dependent libraries that don’t properly handle a server reload.

Since there are multiple libraries with problems and the workarounds required would be rather involved, we have just changed the Admin Console to tell the user a manual server restart is required.

**Isomorphic** · 2 Mar 2020, 12:10

Update on this: as of March 3, 2020 builds of SmartClient 11.0 and newer, the container will properly auto-restart so long as you are running our SDK (as opposed to, say, deploying the entire contents of the SDK in your own container). We auto-detect both cases and the popup after you make a change in the Admin Console will let you know whether the server is auto-restarting or whether you need to manually restart.

Announcement

CONNECTING TO SQLSERVER 2008 R2 - SmartClient_v120p_2020-02-13_Evaluation

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment