Hi all :)
hehe sorry .. lol 1st of all iam new here :) ... and i really liked this site its very informative :) .. and iam sure i will enjoy being a member here..
before when we do a site we choose the database access but this time it will be connected to the oracle database(sql+) , my question is will the jsp code change ? ... and plz if u may write some examples i will be thankful :confused:
tc..
Of course there will be some changes, but they should be minor. Except that, from other examples I've seen, most of your SQL statements will need to be rewritten.
Thanks masijade :) .. for replying back ..
well i guess we need to do it the old way .. because we dont have time to review all things again ...
if done properly, your JSPs won't have anything to do with the database so they won't change.
Your servlets won't have much to do with the database so they most likely won't change either.
Only your ORM mapping files and configuration files would change to take the different database configuration into account.
if done properly, your JSPs won't have anything to do with the database so they won't change.
Your servlets won't have much to do with the database so they most likely won't change either.
Only your ORM mapping files and configuration files would change to take the different database configuration into account.
But you know very well, that all of the above is, in this case, not true. ;-)
But actually if they are going from Acess to Oracle (which is what I read from the original post), then where ever it is that they have their SQL, those statements will change because of all this "[fieldname]" stuff (At least that is what I have seen from every example/problem where Acess is asked about. Whether that is how it is done or not, I don't know, I don't use Access).
But, as you said, that should not be in the JSP at all, and only sparingly, at most, in the Servlets. Some Custom Tags, and other context items, could be be in for some major changes though (SQL wise as I said).
Thanks jwenting and masijade. What both of you said is right, there will be only slight changes inthe code.
there should be no custom tags relying on SQL statements at all...
And I seriously doubt someone learning the ropes has a need for any server specific SQL extensions, they should stick to standard SQL92 which is just about fully portable.
Sorry, jwenting, I was thinking of beans and wrote tags, but that is beside the point.
What I was getting at, is they mentioned using Access for their database before, and from what I have gleaned (I could be completely wrong on this, but it doesn't appear so) Access allows spaces in Field/Column names as long as you then enclose that name in brackets "[ ]" in the SQL statements (and there appear to be other reasons as to why people may want enclose them, as well). This (correct me if I am wrong), AFAIK, is not allowed in standard SQL, but (at least it seems so) nearly everyone that uses Access does this, and so, to make it uniform, often then enclose all field names in brackets. This will definately need to change.
We both know they should stick to SQL92 (and I do so as long as it is possible), but most of the time they do not know what that is, and do not look it up. They have the database they use in front of them, and see that they are allowed (in that database) to do "so and so", and so they do "so and so".
That might not be the case here, and I will truely applaud them if that is so, but I seriously doubt it.
SQL indeed doesn't allow spaces.
The fact that Access does allow them doesn't mean you should use them...
I've used Access, yet never used spaces in table or column names (maybe because I learned SQL before starting to use Access).
If that database has some non-standard features in it, it's past time for some dataconversion to make it better :)
We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.