I have a DB2/zOS database that I need to access. When I create the connection on DBeaver it tests fine and when I open the connection it lets me browse schemas and tables.
The top stacktrace gives a generic SQLError, but I think the culprit is a java.nio.charset.UnsupportedCharsetException: Cp280.
I'm pretty sure it's a query problem (as opposed to a ResultSet problem) because even if I type gibberish in the query it throws the same exception.
I think it's a problem with my particular machine as trying it on my coworker's PC it goes through without a itch. We use the same version of DBeaver, the same connection, the same VPN and the same drivers. I've already tried updating my db2jcc4.jar to the latest 10.1 release, remaking the connection (although with the same settings) and rebooting my PC.
Would really appreciate some help. Thanks.
My thanks to Gord for trying to help, unfortunately it seemed like it was a DBeaver bug that was fixed in version 6.1.2, which came out yesterday. It works fine now.
Related
I've run into an issue with IntelliJ IDEA 2020.1.2, build #IU-201.7846.76 that I have no idea how to begin troubleshooting.
My SQL Server database is up and running just fine (our client applications and SQL Server Management Suite have no issues), but when I try to query it from within IntelliJ, I get no results and an error message that consists only of a period (.):
The query itself does not matter as even this most basic of queries has the exact same result:
SELECT * FROM table_name;
Obviously, I am having a hard time finding a solution for something so vague by searching here or the web.
This is new behavior as of today; yesterday the queries were working just fine.
What does this error "message" mean and how can I determine the cause?
There seems to be a known issue in this version of the JetBrains Runtime, per https://youtrack.jetbrains.com/issue/DBE-10839.
Updating the driver, as suggested, did not resolve the issue for me. Instead, rolling back to IntelliJ IDEA 2020.1 worked out.
i got this problem with postgreSQL, when i do a simple query of anything (CRUD), sometimes it works and almost always shows this message:
Not connected to the server or the connection to the server has been closed.
I don't know how to solve it and it started to irritate me, anyone know how to fix it?
UPDATE 1
I have been searching and it seems the pgadmin4 the problem (it seems because it's not 100% developed yet), i have been using pgadmin3 and that error doesn't show up.
solution is:
select the database where you lost the connection.
then on the right hand side select SQL
For example in the picture (shopdb) is the db where I lost the connection to.
After that PgAdmin will ask you if you would like to reconnect to this database...
click ok
you will notice a message retreiving data from the server
The reason this happened for me was a syntax error in the query. Check your syntax and try again, maybe this suffices
This issue has been fixed.
Upgrade to pgAdmin4 version 2.0. https://www.pgadmin.org/download/
I have similiar problem before, im using postgre 9.6.1-1
I can do select without condition (ex: select * from foodtable) and i can do insert too.. But if i do select or edit or delete using a condition (ex: select * from foodtable where taste='sweet') the output is like your
Not connected to the server or the connection to the server has been closed.
I try reinstall (After uninstall delete all leftover data) and delete C:\Users\yourUserName\AppData\Roaming\pgAdmin (delete all data inside pgAdmin Folder)
And its works
Update-> Your table name and field name must lowercase
Can you run & provide output of these sql queries from pgAdmin4?
1) SHOW SERVER_ENCODING;
2) SHOW CLIENT_ENCODING;
And what is the encoding set for your current database connection on which you are trying to run query (Right click on your database, click on Properties > Definition Tab > Check Encoding, Collation & Character type) ?
I'm suspecting you are facing issues due to encoding.
Change the versión of pgAdmin, use pgAdmin 3, its a problem frequently between Windows 10 and pgAdmin4.
just change the column name and run the query , it worked for me.
my column name was timestamp, it conflicted with datatype so i changed timestamp by _timestamp
Juuuuust in case someone googled this post like i did.
If you have JSON column AND you want to see ANY result in pgAdmin, cast JSON into VARCHAR like
SELECT id, metadata::VARCHAR FROM data_table;
It doesn't matter if content is NULL or not, JSON doesn't work. Maybe there are other types or values that can't be parsed by pgAdmin as well.
Note: you can still insert values and recieve them after cast, so the problem is on JS side (put one more coin into your "Hate JS" jar).
We have just experienced this on a standalone windows machine.
After reinstalling things and looking everywhere (logs, running psql in shell - all was good) then we found out that it was an older firefox that was the culprit.
So - please ensure that your browser is up to date :-)
I solved this. I pressed F7 or Explain in drop-down list near the Execute button. Then I saw where exactly the trouble was. pgAdmin4 didn`t like the name of my column. Then I went to problem column and renamed it.
I have same problem
but i can create DB and table successful
and my version is:
window10 pro x64
9.5 (X86)
pgAdmin4
after i change to 9.4 (X86)+ pgAdmin3 is no more error.. and the table i create by 9.5 can be use(insert data) in pgAdmin3
I am using the pgadmin version 4.6 which is the current release as for now.
I could only solve the problem by running query inside
DO $$ ... BEGIN ... END $$;
block.
In case anyone still looking for an answer like me.
I was getting this error when running a long series of queries in a transaction. Then when I ran them separately, it didn't loose the connection. Still no idea why it actually happens...
My operating system is windows 10.
pgAdmin Version - 4.5
I was getting this error when executing scripts, downgrading to pgAdmin version 4.3 fixed the issue for me.
I have strange effects when retrieving columns of type DATE from SQLServer2008 using the Microsoft JDBC-Driver version 3.0 when running under the official Oracle JDK 1.7.0. Host OS is Windows Server 2003.
All Date columns are retrieved as two days in the past with respect to the value actually stored in the column.
I cooked up a minimal code example the test this out (Test table and data):
CREATE TABLE Java7DateTest (
dateColumn DATE
);
INSERT INTO Java7DateTest VALUES('2011-10-10');
Code:
public class Java7SQLDateTest {
public static void main(final String[] argv) {
try {
Class.forName("com.microsoft.sqlserver.jdbc.SQLServerDriver");
Connection connection = DriverManager.getConnection(
"jdbc:sqlserver://192.168.0.1:1433;databaseName=dbNameHere",
"user", "password");
PreparedStatement statement = connection.prepareStatement("SELECT * FROM Java7DateTest");
ResultSet resultSet = statement.executeQuery();
while (resultSet.next()) {
final java.sql.Date date = resultSet.getDate("dateColumn");
final String str = resultSet.getString("dateColumn");
System.out.println(date + " (raw: " + str + ")");
}
resultSet.close();
statement.close();
connection.close();
} catch (final Throwable t) {
throw new RuntimeException(t.getMessage(), t);
}
}
}
Running this code on above configuration prints: "2011-10-08 (raw: 2011-10-08)".
Under JRE 1.6.0_27 it prints: "2011-10-10 (raw: 2011-10-10)"
I could not find anything that seems to relate to my problem with google, so I'm assuming that its either something stupid I overlooked or nobody is using Java7 yet.
Can anybody confirm this problem? What are my alternatives if I still want to use Java7?
Edit: The problem occurs even when running with -Xint, so its not caused by Hotspot bugs.
Edit2: Old drivers (Microsoft 1.28) work properly with JDK1.7.0 (we were using that driver until maybe two years ago, I think).
jTDS also works perfectly fine with the example. I am considering switching to jTDS, but I am reluctant to do so because I have not the faintest idea what the effects on our productive environment may be. Ideally it should just work, but that what I believed when I switched my dev box to Java7, too.
There is one pretty fat database in the production environment, that is too big to create a copy of, for testing (or rather our server has so little disk left). So setting up a test environment for that one app is not straigthforward, I would have to stitch up a shrinked database for that.
Edit3: jTDS has its own set of catches attached. I found a behavioral difference that breaks one of our applications. ResultSet.getObject() returns different object types for SmallInt columns depending on driver (Short vs Integer). Also jTDS does not implement JDBC4 Connection interface, Connect.isValid() is not supported.
Edit4: I noticed last week that MSSQL-JDBC 3.0 refuses to connect to any DB after I updated to JDK1.6.0_29. jTDS it is then... we switched the productive server yesterday (I fixed tow places where the application was relying on peculiarities of the driver), and so far we had have no problems.
Thank you for your feedback. The Microsoft JDBC Driver for SQL Server does not yet support JRE 1.7.
We are aware of the getDate issue between our JDBC driver & JRE 1.7 and we are looking into publishing a hotfix to enable customers to move forward with non-production testing of our driver with JRE 1.7.
We will publish a link to the hotfix on our blog once available.
http://blogs.msdn.com/b/jdbcteam/
The hotfix is now available. http://blogs.msdn.com/b/jdbcteam/archive/2012/01/20/hotfix-available-for-date-issue-when-using-jre-1-7.aspx
Our blog also contains information on the known issues with JRE 1.6u29 & 1.6u30.
Shamitha Reddy
Program Manager - Microsoft JDBC Driver for SQL Server
I don't quite have an answer for you. But, I've recreated your situation as you described. It is the same with the jdbc driver v3.101 and v3.202 and v4.ctp3 when run under jdk1.7. However, the v2 driver from MS gives your expected answer both under jdk1.6 and jdk1.7. If you need a quick fix and can move to an older jdbc driver, that may work for you.
Other thoughts are on how the MS jdbc driver handles dates and conversion of Date objects between SQL Server and the jvm. Since the storage of the date is without a time zone, the interpretation of the Date object by the driver is based on the default time zone for the machine running the jdbc driver. For instance, if you store a smalldate of '2011-10-11 12:00' and retrieve it from a machine with the default time zone set to GMT-7 then the resulting UTC time of the Date object would be '2011-10-11 19:00'. It could be that there is some change in jdk1.7 that impacts this conversion process in the driver resulting in a wild offset. You might experiment with the ResultSet.getDate(column, Calendar) method to see if a Calendar with a specific time zone gets you the result you want or helps make sense of why you are seeing the strange offset in the conversion.
I don't have a SQL Server setup, but I can't reproduce your problem with PostgreSQL 9.0 and MySQL 5.1 on Windows 7 x64 with JDK 1.7.0. So JDK 1.7.0 can be excluded from being suspect. I have the impression that the SQL Server JDBC driver is to blame here. I'd suggest to use the jTDS JDBC driver instead. It has always been praised for its better performance and stability as opposed to the MS-provided SQL Server JDBC driver.
Information and download link for the hotpatch from Microsoft Support can be found here:
http://support.microsoft.com/kb/2652061
I was experiencing the same issue, where the date would be off by two days, and this hotpatch fixed it.
This is also an issue in OpenJDK 1.6.0_20. However, the mssql driver works fine with Suns JRE 1.6.0_16.
Provide Used: Microsoft OLE DB Provider for SQL Server. Can anyone help me with this..
I was trying to connect with LLBLgen
This MSDN blog page has some useful on this...
http://blogs.msdn.com/sql_protocols/archive/2006/12/02/understanding-kerberos-and-ntlm-authentication-in-sql-server-connections.aspx
In my case, I found the account was locked.
Reason was I previously, on another machine more than 3 times tried to login.
It did not recognise me - and tthen finally it locked my account.
Reopening account made all work fine.
br
Jan
The error you get is almost always caused by a problem with using Windows Authentication. Please try switching to a SQL server login (username/password), or make sure your current Windows login has access to the SQL server and database you're trying to connect to.
-Edoode
I fixed this by mapping a drive to the server running MSSQL. This seemed to generate some kind of trust that allows MSSQL to connect without this error even after a reboot.
I used to get this error sometimes when connecting to my local SQL Server with Windows Authentication. I never fixed it unfortunately - it went away when I reinstalled windows.
I think a reboot used to fix it - have you tried that? Not exactly the best solution, I know :P
Try to synchronize your date and time with the your domain's. The SSPI issue may be related to Active Directory authentication problems, some of them related to date and time changes. This is very simple to check and fix. Try it out!
There is a Microsoft KB article that addresses many of the reasons for this area (KB811889) at the following URL: http://support.microsoft.com/kb/811889.
A lot of Googling shows that one of the diagnostic steps helped most people who encountered the issue.
I recently had this exact issue where I'd get this error only when authenticating with certain accounts, but not others. Ultimately what was causing my problem was not mentioned in any KB or article I found on the net, but through trial and error I discovered that when the account used through SSPI authentication to SQL Server (2k8) happened to be in a large number of groups (in my case over 250) you would get the "Cannot Generate SSPI context" error. I suspect it has something to do with overflowing the security token that Kerberos uses and have seen similar strange authentication problems for user accounts in a large number of groups.
I get the problem when I have the time set differently on my client machine than either the server or the AD machine ( I was trying to test into the future).
Short Answer: Have you recently change the user the service is running as? Was there a system crash?
Long Answer:
I know this is old, but I want to post my experience that I just had.
We had spent hours Googling and found nothing that worked.
Eventually we ran across a set of actions that could cause this:
If you change the user that the Sql Server runs as (e.g. from Local System to a domain usr) and do certain updates and the server doesn't safely reboot -- you get this.
So, we set things back to Local System and bam it worked. Swapped it to the domain user, no worky worky. Ok. Swapped it to Local System, rebooted, swapped it to domain user, rebooted, bam -- worky worky. All was good in our world. Later that morning it crapped out again... still working on that now but the priority is changing and I'm not sure we're going to continue work on this problem so I wanted to post something in case this happens to someone else.
What caused ours was we did an update and, apparently, we learned that it's bad practice to let Sql Server run as Local System so we changed it to a domain user. We never rebooted, but restart the service. A month later, we do updates. We don't reboot. A month goes by and a power strip fries causing the server to have an unexpected shutdown. Yet another month later we find out problem because we rarely connect to this particular database (Interestingly, Sql Server 2008 worked fine... it was only 2005). Or... at least this is the best we've come across.
Our admin guy doesn't like Vista and likes to blame everything on Vista (refuses to let us test Windows 7)... so he Googled "sspi vista" or something like (I know it had sspi and vista, but it might have had another one... in case you need to Google it was well) that and ran across an article that pretty explained our scenario after we had a meeting we all remember these pieces and placed this picture together.
In my case, the time synchronization issue in the Windows 2003 domain environment was actually the issue.
This was quite easy to overlook as the two had been on two different time zones, whilst showing the same times on their clocks; which in effect was about 1 hour apart.
So other than the time on their watches, check the time zones as well.
Occasionally, on a ASP (classic) site users will get this error:
[DBNETLIB][ConnectionRead (recv()).]General network error.
Seems to be random and not connected to any particular page. The SQL server is separated from the web server and my guess is that every once and a while the "link" goes down between the two. Router/switch issue... or has someone else ran into this problem before?
Using the same setup as yours (ie separate web and database server), I've seen it from time to time and it has always been a connection problem between the servers - typically when the database server is being rebooted but sometimes when there's a comms problem somewhere in the system. I've not seen it triggered by any problems with the ASP code itself, which is why you're seeing it apparently at random and not connected to a particular page.
I'd seen this error many times. It could be caused by many things including network errors too :).
But one of the reason could be built-in feature of MS-SQL.
The feature detects DoS attacks -- in this case too many request from web server :).
But I have no idea how we fixed it :(.
SQL server configuration Manager
Disable TCP/IP , Enable Shared Memory & Named Pipes
Good Luck !
Not a solution exactly and not the same environment. However I get this error in a VBA/Excel program, and the problem is I have a hanging transaction which has not been submitted in SQL Server Management Studio (SSMS). After closing SSMS, everything works. So the lesson is a hanging transaction can block sprocs from proceeding (obvious fact, I know!). Hope this help someone here.
open command prompt - Run as administrator and type following command on the client side
netsh advfirewall set allprofiles state off
FWIW, I had this error from Excel, which would hang on an EXEC which worked fine within SSMS. I've seen queries with problems before, which were also OK within SSMS, due to 'parameter sniffing' and unsuitable cached query plans. Making a minor edit to the SP cured the problem, and it worked OK afterwards in its orginal form. I'd be interested to hear if anyone has encountered this scenario too. Try the good old OPTION (OPTIMIZE FOR UNKNOWN) :)