Getting an exception in session.createQuery("from Issue") where Issue has several many to one mappings (object for foreign key). Most succinctly:
INFO: could not read column value from result set: ADDITIONAL25_26_; The value supplied cannot be converted to BIGINT.

I added nullable=true to mapping, thought it would fix it, but not. This is probably the first null foreign key encountered in the read. Thanx

Hibernate version:
3.2 (Annotations 3.3)

Mapping documents:
(relevant field, ADDITIONAL25_26)
@ManyToOne
@JoinColumn(name="ADDITIONAL_CONTACT", nullable=true)
Contact additionalContact=null;


Code between sessionFactory.openSession() and session.close():
Session session = HibernateUtil.getSessionFactory().getCurrentSession();
session.beginTransaction();
List result = session.createQuery("from Issue").list();
session.getTransaction().commit();
(throws in session.createQuery)

Full stack trace of any exception that occurs:
(top of; ADDITIONAL25_26 is above many to one column)
INFO: could not read column value from result set: ADDITIONAL25_26_; The value supplied cannot be converted to BIGINT.
Oct 30, 2007 11:58:48 AM org.hibernate.util.JDBCExceptionReporter logExceptions
WARNING: SQL Error: 0, SQLState: 22000
Oct 30, 2007 11:58:48 AM org.hibernate.util.JDBCExceptionReporter logExceptions
SEVERE: The value supplied cannot be converted to BIGINT.
Oct 30, 2007 11:59:22 AM org.apache.catalina.core.StandardWrapperValve invoke
SEVERE: Servlet.service() for servlet support threw exception
java.sql.SQLException: The value supplied cannot be converted to BIGINT.
at net.sourceforge.jtds.jdbc.Support.convert(Support.java:570)
at net.sourceforge.jtds.jdbc.JtdsResultSet.getLong(JtdsResultSet.java:661)
at net.sourceforge.jtds.jdbc.JtdsResultSet.getLong(JtdsResultSet.java:984)
at org.hibernate.type.LongType.get(LongType.java:28)

Name and version of the database you are using:
SQL Server 2000 (JTDS JDBC driver)

The generated SQL (show_sql=true):
select issue0_.ISSUE_ID as ..., issue0_.ADDITIONAL_CONTACT as ADDITIONAL25_26 ...

Well, the problem turned out to be predictably idiotic, if everything else was correct, namely the database field was named like the other foreign key objects but was merely a string, not an actual foreign key, just needed to look at the values for that column...duh-oh...