Skip to Main Content

SQL Developer

Announcement

For appeals, questions and feedback about Oracle Forums, please email oracle-forums-moderators_us@oracle.com. Technical questions should be asked in the appropriate category. Thank you!

Interested in getting your voice heard by members of the Developer Marketing team at Oracle? Check out this post for AppDev or this post for AI focus group information.

Importing from excel doesn't work on date fields

711683Jul 13 2009 — edited Oct 21 2009
I'm trying to import from an excel file, and two of the fields are dates. When I look at the resulting Insert statement, I see this:

to_date('39896.0', 'MM/DD/YYYY HH:MI:SS')

Which, of course, does not work. Where is this '39896' coming from?

I've seen a few other people with this issue, but no solutions. Is there a suggestion box or something? This tool could be great, but as it stands, even when it works it's too hard to use.

Comments

843793
Well, this was a shot in the dark, but I tested it and it seems to be the problem: remove the parens around i.next()!

After doing so, running the code in your post instead provides a "NoSuchElementException" from the iterator (completely expected). I'm not sure if this a bug in the compiler, or if it has something to do with the way the code gets expanded. Maybe if someone thinks about it long enough they'll be able to come up with a reason.
843793
Why would you expect to use those parens like that anyway?
843793
Why would you expect to use those parens like that
anyway?
I can see that the parens are redundant - and as the other responder pointed out, the error goes away when they are removed...however, I'm still curious...

Firstly, is it actually an error to use the parentheses in that way?

Secondly, although the offending line is executed in the example I gave, the code that I pulled the example from is a bit stranger - when I try to instantiate a class (call it B), that contains a method with the redundant parentheses, I get the same error - even though the offending line isn't executed (I can post the code tonight if anyone is interested).

Gareth
843793
Here's the code:

import java.util.*;
class A {
public static void main (String argv[]) {
B bb = new B();
}
}

class B {

void methodC() {
ArrayList<Boolean> B = new ArrayList<Boolean>(10);
Iterator<Boolean> i = B.iterator();
boolean b = (i.next()).booleanValue();
}
}

843793
This is definitely a bug in the compiler. The bytecode generated for B.methodC() is:

Codeview "bytecode" for void B.methodC():
#3/Test.java:12 - new class java.util.ArrayList
#4/Test.java:12 - dup
#5/Test.java:12 - bipush (byte)10
#6/Test.java:12 - invokespecial public java.util.ArrayList(int)
#7/Test.java:12 - astore_1 lv_1
#8/Test.java:13 - aload_1 lv_1
#9/Test.java:13 - invokevirtual public java.util.Iterator java.util.AbstractList.iterator()
#10/Test.java:13 - astore_2 lv_2
#11/Test.java:14 - aload_2 lv_2
#12/Test.java:14 - invokeinterface public abstract java.lang.Object java.util.Iterator.next()
#13/Test.java:14 - invokevirtual public final boolean java.lang.Boolean.booleanValue()
#14/Test.java:14 - istore_3 lv_3
#15/Test.java:15 - return

and it's clear that between instruction #12 and instruction #14 a typecast is missing.

I'll add this to my list of known prototype compiler bugs at
http://cag.lcs.mit.edu/~cananian/Projects/GJ/
1 - 5
Locked Post
New comments cannot be posted to this locked post.

Post Details

Locked on Nov 18 2009
Added on Jul 13 2009
16 comments
3,813 views