I'll try to ping Lance Anderson (JDBC spec lead) about the JDBC and ODBC
version issue.
There is not specific tie to a given ODBC version. As JDBC evolves, we
might choose to evlove methods that originated from ODBC, which many
have. Do not assume there will always be a 1 to 1
Kristian Waagan (JIRA) wrote:
[ http://issues.apache.org/jira/browse/DERBY-1095?page=comments#action_12370077 ]
Kristian Waagan commented on DERBY-1095:
I see your point, but I still think Derby is buggy. The repro script executes a
i did not look at the patch, just make sure you are not throwing an
SQLException on close(), should be a no-op
Knut Anders Hatlen (JIRA) wrote:
[ http://issues.apache.org/jira/browse/DERBY-1060?page=all ]
Knut Anders Hatlen updated DERBY-1060:
--
No revisions to getFunctionParameters. this was settled in Dec, just EG
confusion. Only thing i changed was the constant
functionParameterReturn to functionReturn as i missed this earlier.
-lance
David W. Van Couvering wrote:
I have noticed on the JDBC4 EG mailing list that this method
We had a long EG discussion on this and the wording changes was the only
way we could provide portability and extendability going forward.
Having vendors just throw their own entries into the ResultSet is not
very portable either nor is the ODBC way of changing column names which
is something
Hi Rick,
There is a limited number of DatabaseMetaData methods have allowed this
to occur as part of the functionality. This was unfortunate IMHO.
-lance
Rick Hillegas wrote:
Hi Lance,
Is it OK for a JDBC3 implementation to return more information than
the spec demands? In particular,
Well, this is handled differently by a variety of vendors. For example
Oracle and the IBM DB2 drivers currently throw an exception for every
case except ResultSet.TYPE_SCROLL_SENSITIVE, ResultSet.CONCUR_UPDATABLE
Some other vendors only follow the guidelines in the javadocs as to
when they
Calling ResultSet.close() a second time will be a no-op and this will
be updated for the PFD of JDBC 4
-lance
Knut Anders Hatlen (JIRA) wrote:
[ http://issues.apache.org/jira/browse/DERBY-1060?page=all ]
Knut Anders Hatlen reassigned DERBY-1060:
maybe i am blind today, but i only see the wording in 14.2.4.2 not
14.2.4.3 WRT othersXXXAreVisible method that u refer to below
Daniel John Debrunner wrote:
Lance J. Andersen wrote:
The wording in chapter 14 of JDBC 3 in sections 14.2.4.1 Updating a Row,
14.2.4.2 Deleting a Row
believe me i know the feeling.
I am not quite sure why the methods below are not mentioned for the
update and insert section.
I will cover this with the EG and discuss possibly clarifying the other
wording u suggested
i think that covers it yes?
Daniel John Debrunner wrote:
Lance J
Right now there is a spec difference WRT calling close subsequent
times on Connection/Statement being a no-op and on ResultSet throwing
an SQLException. I expect the restriction on ResultSet.close will be
lifted
-lance
Daniel John Debrunner (JIRA) wrote:
[
Well unfortunately, i am afraid your milage is going to vary here.
The tutorial and reference, while informative is not part of the
specification. Some vendors might have used the additional details
when crafting their implementation others might have just followed the
spec. I will raise this
definitely need to make the scripts more portable
i had hoped to do it but just not enough cycles in the day right now.
There might be a JIRA already there for this
Kathy Saunders wrote:
Andrew McIntyre wrote:
This sounds reasonable to me. I was a little hasty in wanting to just
get rid
Daniel John Debrunner wrote:
Andreas Korneliussen wrote:
Currently Derby supports a limited combination of ResultSet types and
Resultset concurrency modes. Common for all the current combinations, is
that Derby can support HOLD_CURSORS_OVER_COMMIT, however for future
changing error codes and SQL States which are not correct in the
current version of Derby should just be considered a bug fix. You can
always , if you feel it is really important, at a property for backward
compatibility.
Daniel John Debrunner wrote:
Kathey Marsden wrote:
Daniel
The purpose of the JDBC Escape syntax is to provide a portable means to
invoke non-portable functions across database backends. You do not
have to have the same function in the database, you just have to make
sure the driver maps the JDBC escape to the correct backend function
Daniel John
Early Draft, Public Draft, Proposed Final Draft, and Final are always
made available of the current spec are all made available via the JCP
for a given JSRE.
The license for non-final drafts does have an expiration period.
Satheesh Bandaram wrote:
The download site is asking for License
to make sure there
are no objections.
David
Lance J. Andersen wrote:
This method was added as various drivers and database vendors all do
this differently. In some cases autocommit is handled explictly by
the drivers themselves, not the backend.
autocommit has been very problematic over
+1
Rick Hillegas wrote:
David Van Couvering wrote:
This vote is for adding Knut Anders Hatlen as a committer to Derby.
+1
This method was added as various drivers and database vendors all do
this differently. In some cases autocommit is handled explictly by the
drivers themselves, not the backend.
autocommit has been very problematic over the years and somedays it
would be great it it never existed
David W. Van Couvering wrote:
According to our most esteemed spec lead, for the new metadata calls
that return a result set, if we don't support the metadata call, we
should return an empty result set.
Can anyone provide me some guidance as to the best way to do this? The
constructor for
useful...
And, Lance, is it really true that every metadata call has to return a
real result rather than throw a Feature not implemented exception?
David
Lance J. Andersen wrote:
David W. Van Couvering wrote:
According to our most esteemed spec lead, for the new metadata calls
+1
Kathey Marsden wrote:
Kathey Marsden wrote:
This vote is for establishing Bryan Pendleton as a committer for Derby.
Please vote +1 if you approve of Bryan as a committer.
+1
The client network driver has, we do it internally.
David W. Van Couvering wrote:
Lance -- it appears that Derby has not been run through the
conformance tests. How does one go about doing that? I would think
that's pretty important.
Thanks,
David
Lance J. Andersen wrote:
The JDBC
Daniel John Debrunner wrote:
Rick Hillegas wrote:
Three months ago, we shelved this topic, promising to return to it
later. I would like to reach consensus on this problem now. In a
nutshell: JDBC4 introduces new methods whose signatures contain
generics. Because of this,
Generics can be used on signatures for existing methods when it makes
sense. If you look at Java SE 5.0, you will see many methods whose
signatures changed (Collections API is an obvious example) without
breaking compatibility with earlier code at runtime.
-lance
Andrew McIntyre wrote:
Connection.close() is supposed to close open Statement objects.
Deepa Remesh wrote:
Should a JDBC driver close the statement objects associated with a
connection when the connection's close() method is called?
I saw this in JDBC 3.0 spec (Section 13.1.3 Closing Statement Objects)
All
David W. Van Couvering wrote:
This is a vote for choosing a logo f
10. [ x] (these all belong together...)
http://issues.apache.org/jira/secure/attachment/12321022/derby_logo_only.jpg
http://issues.apache.org/jira/secure/attachment/12321023/derby_with_text.jpg
Myrna,
Try having the timestamp values closer together and give it a go.
-lance
Myrna van Lunteren wrote:
Hi,
Is this a bug? It seems to me it is...
In ij:
ij create table tab1(TMSTCOL1
TIMESTAMP, TMSTCOL2 TIMESTAMP);
0 rows inserted/updated/deleted
ij INSERT INTO tab1
once assuming the issue is a range issue
based on what a given backend supports
Myrna
On 11/28/05, Lance J. Andersen [EMAIL PROTECTED]
wrote:
Myrna,
Try having the timestamp values closer together and give it a go.
-lance
Myrna van Lunteren wrote:
Hi
it handles,
not ODBC or JDBC.
JDBC/ODBC define that the return type range for the TIMESTAMPDIFF
function is an INTEGER regardless of what the backend engine supports.
Dan.
Myrna
On 11/28/05, *Lance J. Andersen* [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
Myrna,
Daniel John Debrunner wrote:
Lance J. Andersen wrote:
JDBC/ODBC define that the return type range for the TIMESTAMPDIFF
function is an INTEGER regardless of what the backend engine supports.
Just to be picky, do you actually see 'INTEGER' anywhere, or just 'integer
Hi Rick,
Rick Hillegas wrote:
Hi Lance,
If ResultSet.getObject() throws an unimplemented feature exception,
should the corresponding ResultSetMetaData.getColumnClassName() throw
an exception? Return null?
A SQLException is the correct Exception to be thrown per the spec when
something is
Amit forwarded info on this, so i think you have what you need.
-lance
David W. Van Couvering wrote:
Thanks, Dan. Can you point me to something that talks more about what
it means to be a valid OSGi bundle?
Lance, do you have any information on how a driver is loaded in JDBC4
using the
Rick Hillegas wrote:
Hi Dan,
Thanks for your comments. Some responses follow. Cheers-Rick
Daniel John Debrunner wrote:
...
Derby has never supported BOOLEAN, so you are not re-enabling it. This
might confuse readers of this spec.
I will wordsmith this.
In order to support BOOLEAN
Daniel John Debrunner wrote:
Rick Hillegas wrote:
I logged this enhancment request because it seemed that re-enabling
TINYINT would be low hanging fruit.
I believe how hard or easy an item is has no relevance to if it should
be included in Derby. The criteria should
Satheesh Bandaram wrote:
Hi Rick,
Rick Hillegas wrote:
We will probably have to collaborate here. If you select an XML
column, the ResultSetMetaData needs to say that the column is of type
java.sql.SQLXML. This, at least, was the consensus of the community
which prevented me
Yeah, that's the same sentence I saw. It's a bit oddly worded. The
"8-bit integer value" makes it sound like a byte. But "value between 0
and 255 that may be signed or unsigned" could mean a "value between
-256 and 255", that is, a 9-bit quantity. I'm putting my faith in the
Daniel John Debrunner wrote:
Lance J. Andersen wrote:
H, that's kind of an awkward place to be in. It seems you want to
add this non-standard SQL type to match other databases, but by matching
the other databases you break the JDBC spec. :-)
I do
Daniel John Debrunner wrote:
David W. Van Couvering wrote:
As I understand it the value of TINYINT is:
- Enables of migration of applications to Derby
- Allows for better use of storage (which goes in line with our "small
footprint" goal)
The reason against it is it is a
Java byte type represents a signed value from -128
to 127, so it may not always be appropriate for
larger TINYINT values, whereas the 16-bit Java short
will always be able to hold all TINYINT values."
This seems to infer JDBC TINYINT range of 0-255.
Satheesh
Lance J. Andersen wrote:
Rick Hillegas wrote:
Hi Satheesh,
TINYINT, as you note, is not an ANSI datatype. It is, however, a JDBC
datatype and is supported by MySQL and SQL Server. Adding it would
grow our JDBC support and help close the feature gap with some
significant databases. I think those are compelling
I am for adding this datatype back. While it may not be part of the SQL
Standard, it is a common datatype supported by multiple vendors. Having
this datatype supported helps with the migration of applications and at
the end of the day making it easier for applications to migrate is more
8-bit integer.
I see this in section 8.3.4
"The JDBC type TINYINT represents an 8-bit integer value between 0 and
255 that may be signed or unsigned."
I don't see anything in that section or elsewhere about "fits in a
byte", in fact I see:
"The 8-bit Java byte type
I do not see this as a requirement for 10.1.2.1. I do think we want to
explore migrating these scripts IMHO.
-lance
Andrew McIntyre wrote:
On Nov 3, 2005, at 7:48 AM, Knut Anders Hatlen wrote:
The ksh scripts work fine on Solaris (tested tar and zip).
Great. (sort of :-) )
I have
Thanks for the useful infomation, but how are you inferring those cursor
context attributes from the JDBC ResultSet being read-only?
A Derby forward only ResultSet, is read only but:
- is not scrollable
- does not have an order by clause
So it fails on two of the context items that make
Bernt M. Johnsen wrote:
Daniel John Debrunner wrote (2005-11-03 19:17:58):
The better approach is to get rid of the scripts and replace them with
ant based startup scripts as it is more portable, especially windows.
I would not expect sh to work against a ksh script across the board
myself anyways.
Knut Anders Hatlen (JIRA) wrote:
ksh scripts should be written in
The JDBC javadocs indicate the following
Note: If this method is called during a transaction, the result
is implementation-defined.
Unfortunately many of the corner-cases such as this will vary from
vendor to vendor so the best thing to do is avoid this type of behavior
in your apps if you
for checking for
read/writeOnly info for base columns.
Again, I am OK with implementing a consensus either way. Hope we can
reach one, quickly. :-)
Satheesh
Lance J. Andersen wrote:
As i mentioned earlier, i will be addressing the lack of clarity in the
JDBC 4.0 spec
i wil look to try and clear this up. This comes like most of the other
metadata from ODBC and it is probably tied to what acces the user was
granted to the specific column . EDR2 which i am pushing this week to
the JCP has many clarifications in the javadocs and spec. Still a long
way to go,
What about the SQLStates that are returned? Some SQL State Class
values might be appropriate. Yes JDBC 4 will help somewhat
lance
Kathey Marsden wrote:
Daniel John Debrunner wrote:
Kathey Marsden wrote:
Daniel John Debrunner commented on DERBY-254:
i am talking to the EG about clarifying this in the spec.
-lance
Daniel John Debrunner wrote:
Sunitha Kambhampati wrote:
I have a question about the binding of parameters using the stream api's
in JDBC
If you set the value for a parameter marker of a preparedstatement to a
+1
Jeremy Boynes wrote:
Rick Hillegas wrote:
I would like to propose that we include JUnit as part of the required
toolkit for Derby developers. Going forward, this will allow
developers to write assertion-based tests. For the moment, this will
not change the existing test harness.
+1
David W. Van Couvering wrote:
Hi, all. Yes, it's your favorite topic. :)
I've been thinking about this further, and I would like to say that
it's time to bite the bullet and address this. I am planning on
piloting this with the i18n work so that I can reuse the
message.properties file
this has all changed... once i close with the EG i will forward
Kathey Marsden wrote:
Philip Wilder wrote:
Lance J. Andersen wrote:
[snip.. ]
■ For Select statements that return a single result set, the
statement is complete when
+1
Rick Hillegas wrote:
+1
Rick Hillegas wrote:
No-one on the user list has objected to the proposed sunsetting
policy for jdk 1.3. Therefore I'm cautiously hopeful that we can
move forward with a vote. Let's wrap up the voting by Friday evening
(12 August, 2005).
Thanks,
-Rick
Please
Satheesh, can you provide an example WRT JDBC metadata as I do not see
an issue there.
more DB info:
Sybase ASE and IAnywhere do not support boolean, you can use bit.
Pointbase supports BOOLEAN
Daffodil supports BOOLEAN
MySQL 4.1 and beyond supports BOOLEAN as a TINYINT(1), that is it s a
. So, I was just saying enabling boolean types is more
involved.
Satheesh
On 8/9/05, Lance J. Andersen [EMAIL PROTECTED] wrote:
Satheesh, can you provide an example WRT JDBC metadata as I do not see an
issue there.
more DB info:
Sybase ASE and IAnywhere do not support boolean, you
there are drops from java.net available. Beta has not yet started
David Van Couvering wrote:
Is 1.6 available? I thought it was still in process.
David
Rick Hillegas wrote:
Please vote on the following proposed policy for Derby's supported
platforms. Mostly, this proposal merely restates
it is a con call
-lance
Philip Wilder wrote:
Kathey Marsden wrote:
Lance J. Andersen wrote:
it is at 12:30pm PST and we are going to cover your Tx queries
Hi Lance,
I am sorry I cannot attend but do hope that we can find someone to
represent Derby on this issue.
Dan, Philip, can
Philip,
Thanks for this. I will discuss with the JDBC 4 EG and report back.
-lance
Philip Wilder wrote:
Lance,
In order to further distill this issue for your EG team I've created
this brief question list (largely based off some earlier questions
from Kathey) that you can pass on to
Kathey Marsden wrote:
Lance J. Andersen wrote:
I am just getting back from J1 and I
have a quite a few emails to wade
through. If/when you hace a cycle, if you can summarize the issues
out
+1
Daniel John Debrunner wrote:
Please vote on making David a committer on the Derby project. The
derby-ppmc believe David will be a great benefit to Derby.
[ ] - Add David Van Couvering [EMAIL PROTECTED] as a Derby
committer
---
My vote: +1
Dan.
The DatabaseMetaData method supportsConvert is used to validate what
the scalar escape function CONVERT can be used for based on the
driver/database combo.
The javadoc for the supportsConvert(arg1, arg2) should clarified a bit
more.
As far as the name of the SQLTYPE for the Convert scalar
+1
ystein Grvlen wrote:
"DJD" == Daniel John Debrunner [EMAIL PROTECTED] writes:
DJD Please vote on making Bernt a committer on the Derby project. The
DJD derby-ppmc believe Bernt will
I am just getting back from J1 and I have a quite a few emails to wade
through. If/when you hace a cycle, if you can summarize the issues
outstanding, i can look at it and discuss with the EG. There are sooo
many emails from derby-dev, it is going to take me quite some time to
digest it all.
i have not had the bandwidth to follow this thread due to J1 and a few
other fire drills. We have made changes to the spec and javadocs in
JDBC 4 to clarify things in these areas. Please take a look and see if
there is still something you feel needs clarified.
Kathey Marsden wrote:
fyi, I am making the following changes based on an JDBC EG
discussion. This will be in the next update of the JDBC 4 EDR javadocs.
Note the wording might slightly change but the 'must' requirement will
not.
-lance
setQueryTimeout
void setQueryTimeout(intseconds)
throws
I will be there...
lance
David Van Couvering wrote:
Hi, all. Since many of us will be in San Francisco during JavaOne, I am
setting up a group lunch during the conference. After polling a number
of you, it appears that the best time is Monday, June 27th, at noon.
Let's get together at a
specification.
-lance
Daniel John Debrunner wrote:
Lance J. Andersen wrote:
you are correct, timeouts are not documented to effect xxxRow()
specifically in the jdbc 3 or 4 spec
Lance, I'm a little confused by your comment.
Who do you think is correct, David or Oyvind
you are correct, timeouts are not documented to effect xxxRow()
specifically in the jdbc 3 or 4 spec
David Van Couvering wrote:
I'm guessing the JDBC spec doesn't have anything to say about this?
Do we know what other drivers do for updateRow() and deleteRow()?
Barring any existing
perhaps it needs to be documented a bit clearer on the derby test
running /development docs?
Shreyas Kaushik wrote:
Same here even I use ij.stratJBMS() in any new tests.
thanks
Shreyas
David Van Couvering wrote:
I thought all the other tests use ij.startJBMS(), not
util.startJBMS().
+1
David Van Couvering wrote:
+1
David
Kathey Marsden wrote:
Satheesh filed DERBY-310 to manage this issue, but to clarify
direction, I thought it worthwhile to submit this to vote:
There are some differences in behaviour when using the client vs the
embedded driver. Examples are
David.
If you are planning on doing this and making a pass throughout the code
to make sure the correct SQLState is set correctly (not just correcting
the message property files), it might be worthwhile to add some type of
marker comment in places where the code will need to be changed for
I have had a report internally where we have 2 unit tests fail with the
DerbyNetwork client driver that did not fail with the DB2 type 4 driver
with Derby.
We have not had a chance to look into this yet in detail yet. If we
can package up the failure, are there any volunteers on the IBM side
Daniel John Debrunner wrote:
Lance J. Andersen wrote:
I have had a report internally where we have 2 unit tests fail with the
DerbyNetwork client driver that did not fail with the DB2 type 4 driver
with Derby.
We have not had a chance to look into this yet in detail yet
Jeremy Boynes wrote:
Lance J. Andersen wrote:
The reality is that there are way too many applications which utilize
java.sql.Driver implementations to depecrate this functionality.
We are in JDBC 4 reducing the boiler plate code by having
DriverManager.getConnection() utilize the Server
I will review this today.
lance
Satheesh Bandaram wrote:
Simple patch to remove UNICODEESCAPE option in IJ.
Satheesh
Index: java/tools/org/apache/derby/impl/tools/ij/ij.jj
===
---
Hi Satheesh,
This looks good.
I noticed that ijConstants.java also has references to unicodeescape,
should these be removed as part of this patch?
Regards,
lance
Satheesh Bandaram wrote:
Simple patch to remove UNICODEESCAPE option in IJ.
Satheesh
Index:
truncate table is a SQL extension supported by many database vendors now
as an optimization over delete table
It is worth adding at somepoint to aid in porting apps from other backends
Mike Matrigali wrote:
The following is sort of ugly, but will work with the current derby
release, and the
i will enter a jira for this puppy
Mamta Satoor wrote:
Is there a Jira entry for this already? If not, it will be nice to
enter one so we keep track of it.
Mamta
On 5/10/05, Lance J. Andersen [EMAIL PROTECTED] wrote:
truncate table is a SQL extension supported by many database vendors now
The reality is that there are way too many applications which utilize
java.sql.Driver implementations to depecrate this functionality.
We are in JDBC 4 reducing the boiler plate code by having
DriverManager.getConnection() utilize the Server Provider Mechanism in
J2SE to load the driver,
I believe that is the key and I discovered that myself the other day.
The master *.outs are included in the derbyingTesting.jar
Mamta Satoor wrote:
Hi,
Did you do a build again after copying the .out file to the master directory?
Mamta
On 5/6/05, ystein Grvlen [EMAIL PROTECTED] wrote:
this more obvious in the testing README some time soon.
Or someone else can, of course.
Myrna
On 5/6/05, Lance J. Andersen [EMAIL PROTECTED] wrote:
I believe that is the key and I discovered that myself the other day. The
master *.outs are included in the derbyingTesting.jar
Mamta
Hi Satheesh,
Sure thing go for it. It looked like another fairly straightforward
fix to continue becoming familiar with the codeline.
It is all yours 8-)
I can do the review if you like.
Regards
lance
Satheesh Bandaram wrote:
Hi Lance,
You are fast... I have a patch ready
Hopefully something simple.
I am trying to just run the jdk14 test suite.
During the run, I see it creates the *.tmp files but i do not get any
*.out files and the jdk14_pass/fail.txt are zero in size.
Any idea as to what the magic is the i am missing?
the above error?
Myrna van Lunteren wrote:
Are you maybe (I'm sure it's a dumb question) running with jdk13?
Check the .sum, and see if there's any helpful info it the
jdk14_skip.txt file?
Myrna
On 5/4/05, Lance J. Andersen [EMAIL PROTECTED] wrote:
Hopefully something simple.
I am
/05, Lance J. Andersen [EMAIL PROTECTED] wrote:
I take it this is with the Embedded Driver
as it looks like the code for the
new Client Driver is returning false.
I can take this if no one else wants it.
Mamta Satoor wrote:
Hi
at the review package and it looks good. Good comments in the
EmbedDatabaseMetaData.java. Just wondered if you ran the existing
tests to make sure nothing got affected by the change.
Mamta
On 5/4/05, Lance J. Andersen [EMAIL PROTECTED] wrote:
Oh, I forgot to mention that i validated
Myrna van Lunteren wrote:
in line...
On 5/4/05, Lance J. Andersen [EMAIL PROTECTED] wrote:
The issue turned out to be that I had a typo in the jar name for
jakarta-oro-2.0.8.jar in the window i was running the tests from.
yeah - that would've been clear only from
])
Lance J. Andersen wrote:
Hi Mamta,
The only test I saw and ran was DBMetaDataJdbc30 when I searched the
codeline. (You saw my notes on my other failures in jdk14 test run, but
this one passed)
I also noticed that the other
Quick question . Do you want me to remove the DB2 Driver completely or
leave it and just add DerbyClient to the CLASSPATH?
I would probably suggest we remove the DB2 Driver but I wanted to
verify what your expectation was here
lance
Samuel Andrew McIntyre (JIRA) wrote:
Network Server
Hi Shreyas,
Which codeline was blurb below that you cut and pasted from as I did
not see the blurb below in the javadocs for
supportsMixedCaseQuotedIdentifiers.
supportsMixedCaseQuotedIdentifiers
public boolean supportsMixedCaseQuotedIdentifiers()
Bernt M. Johnsen wrote:
Daniel John Debrunner wrote (2005-05-02 09:23:59):
There is also an issue on windows of a classpath size. I know i have
been burnt by this before.
David Van Couvering wrote:
Good points, although I am very wary of a huge long set of jars in the
classpath, an invitation to confusion and difficulty for our users.
Couldn't we have a
Perhaps it is me, but I swear i used to be able to assign myself a
jira. Now i cannot find a way to do this.
Any special access needed?
thanks, i just sent him an email.
Regards
lance
Andrew McIntyre wrote:
On Apr 29, 2005, at 11:44 AM, Lance J. Andersen wrote:
Perhaps it is me, but I swear i used to be able to assign myself a
jira. Now i cannot find a way to do this.
Any special access needed?
To assign issues to yourself
That is a very good point. You could also use lib/ext as well and set
the property java.ext.dirs property accordingly
Jeremy Boynes wrote:
Lance J. Andersen wrote:
There is also an issue on windows of a classpath size. I know i have
been burnt by this before.
I think most projects of any
always dump the JDBC drivers into the appservers configured
lib/ext directory.
Regards
Lance
David
Lance J. Andersen wrote:
That is a very good point. You could also use lib/ext as well and
set the property java.ext.dirs property accordingly
Jeremy Boynes wrote:
Lance J. Andersen wrote
101 - 200 of 215 matches
Mail list logo
