Hi,
i think we can handle this problem now. If you request a fault statement
like "SELECT * FROM scheme.table; commit" the programs iSQL and Squirrel
SQL tells me that these statements are fault. DB-Visualizer doesn't
check if the statement is correct and send this to the controller. The
Controller will send this statement to the databases and the databases
reply a fault-message like this:
Statement:
SELECT * FROM scheme.table; commit
Error:
ERROR: Error »Syntaxerror« at »SELECT«
ROW 2: SELECT * FROM scheme.table;
So i think that the controller-parser think this is correct ()
because of the correct Select-Statement and ignore the "commit" after
the semicolon. So the problem is, that the Controllers can't handle this
problem.
Do you think this might be the problem?
cheers,
Chris
Christopher Hartung schrieb:
Hi @all,
the problem is, that you can use our environment with every
database-tool like Squirrel-SQL and iSQL. But if we are using
DB-Visualizer we get problems like you can see below.....Do some people
get the same problems using DB-Visualizer or do somebody have a
workaround for this?
Thanks for your help and reply
Greetings
Chris
Christopher Hartung schrieb:
Hi @ all,
last week you perfectly solved one of my problems, but now i've a new
one :)
If i connect to the cluster via a database-program (especially
db-visualizer ) and the cluster runs well for days, a statement like
database.table (destination,short_description) VALUES ('3123','test')
puts the db-visualizer in a graceful status => it's hang. I can only
destroy the running program. If i want to create a backup now the
cluster get in a waiting state because a request is still there. A
"dump scheduler queues" and a "dump request" statement have this results:
table(admin) > dump scheduler queues
Active transactions: 0
Transaction id list:
Pending read requests: 0
Read request id list:
Pending write requests: 1
Write request id list: 8
table(admin) > dump request 8
Request id: 8
query: INSERT INTO database.table (destination,short_description)
VALUES ('3123','test')
parameters:
login: postgresc
autocommit: true
transaction id: 8
cacheable status: CACHEABLE
isolation level: TRANSACTION_UNDEFINED
start time: 1174992471910
end time: 0
timeout in seconds: 0
locked tables:
kontor.abgabeart
persistent connection id: 0
client ip address: 10.100.8.112
kontor(admin) >
My question is, how can i destroy some session/requests like this? The
backup-process is waiting for the request to complete...and this is a
never ending story ;)
I don't have this problem with squirrel-sql!!
thx for your help
--------------------
chris
_______________________________________________
Sequoia mailing list
[email protected]
https://forge.continuent.org/mailman/listinfo/sequoia
