Without a database, the SQLJ translator can perform only offline checking of your SQL code. If you want to get your database involved, that is, you want SQLJ to perform online checking, then you must tell the translator how to connect to it. Specifically, you must supply a user name (corresponding to the database schema you want to connect to) and a password.

sqlj -user=scott/tiger MyFile.sqlj

Of course, you also want to be able to say which database you'd like to talk to and how — that is, with which protocol. Because SQLJ uses JDBC underneath, this is accomplished by a JDBC URL. By default, SQLJ uses the OCI8 JDBC URL. This is the string "jdbc:oracle:oci8:@" - see Section "1.4 Getting Connected". However, you can also specify your own URL. For example, you can request the Oracle OCI7 driver (if available) as follows.

sqlj -user=scott/tiger@jdbc:oracle:oci7:@ MyFile.sqlj

And there is a special shorthand notation if you use Oracle's thin JDBC driver.

sqlj -user=scott/tiger@my_host:1521:my_oracle_sid MyFile.sqlj

Finally, you can use "shorthand" on the command line and write -u instead of -user=, as follows.

sqlj -u scott/tiger MyFile.sqlj

• The translator will try to check your SQLJ programs against the database if, and only if, you specify the -user option (or -u shorthand).
• The -user and -u flags are two of the 46 or so option flags that SQLJ accepts. To see a synopsis of all options, refer to SQLJ Developer's Guide and Reference, Chapter 8, Table 8-1 "SQLJ Translator Options". Or issue sqlj -help to get an introduction to the most important ones. See also Section "4.1 The Translator Is Talking Back".

1. (*) When run offline, SQLJ checks the legality of Java types used in SQL statements, and some (rather superficial) syntax. Show some errors caught by the translator offline.
2. (*) When run online, SQLJ additionally checks the shape of SELECTs, type compatibility between SQL and Java, and asks the database to parse SQL DML statements. Show some errors caught by the translator online, but not offline.
3. (*) Show some errors caught only at runtime, but not at translation time.
4. (*) In the examples above, the password was given on the command line. Usually, you want to avoid doing this.
   (a) What happens if you omit the password in the -user option?
   (b) You can use the sqlj.properties file for storing command line options used for sqlj invocation. Investigate the format of this file, and store the password information in it. What happens if an option is given in both the command line and the sqlj.properties file?