Paul Sturrock

...if you are using a PreparedStatement.

Do the Jars you have added contain the class com.itextpdf.text.pdf.PdfReader?

OK. Do you commit your transaction after thin insert?

Use SQL Server Configuration Manager to check. By default, SQL server is not configured to allow connections over TCP/IP.

I think it is easy to work with Oracle rather than working with MS,they alwayz make things complicated!

never heard anyone call Oracle easier to configure than SQL Server before.

Is SQL Server configured to accept connections over TCP/IP? Why are you trying to connect to the tempdb? If your username and password correct?

Hemant Thard wrote:hi Enrique,

have you enabled second level cache for your customer class.

best way for you to check is by looking at the hashcode of returned list.
if the same hashcode is returned every time you refresh the page, then you can be certain that the problem is with your hibernate configuration(assuming the bean is request scope)

A better way is to look at your configuration. Enabling the second level cache and the query cache is a fairly involved affair, you are not going to do it by accident. At the very least you would need to have a query marked as cachable, which you don't, so it is not Hibernate's Query cache that is causing this.

What do you mean by "send physically"?

JMS supports a bunch of message types. You can use a different type (e.g. and ObjectMessage or BytesMEssage) if you like, but sending XML as text makes the most sense to me.

I don't understand your question, what is it you are asking?

There are workarounds for this. You can define the all properties as a composite key. It means all rows now have to be unique, but this probably is the case anyway (you have no other way to uniquely identify a row otherwise). Entities without primary keys are cannot be relational data - these are arguably invalid in the data model as is regardless of whether you use Hibernate.

The easiest way to fix this is to add a surrogate key to this table.

When you insert your record do you commit the transaction?

This might be a good example.

What have you written so far? What exceptions or unexpected behaviour is occurring?

I'm investigating securing an application deployed on JBoss using TAM with WebSEAL and am currently getting an authorization problem. It looks like the WebSEAL junction is correctly authenticating access to the web application, however the principal passed to the EJB container has no roles. Examining pdamin I can see my user exists, and is in a group.

TAM seems to rely on the JBoss ClientLoginModule and a custom valve to propagate the principal to the EJB container. Does anyone know if WebSEAL can propagate roles with a principal to an application server that is not WebSphere? Do I need to enable JACC to have JBoss query for roles itself? My understanding of JEE suggests I shouldn't have to do this, but nothing I change seems to influence the roles on the principal.

I think Swastik is just misreading your SQL - assumign it check by both username and password. If you have already matched your user by username and password in SQL, what extra functionality does your check in Java provide? You only check by username; if you change your SQL to check by both credentials your Java code is redundant.

How is your number defined in Oracle? Assuming it allows for at least two decimal points then you can format this how ever you like using the JSTL format tag.