Win a copy of Testing JavaScript Applications this week in the HTML Pages with CSS and JavaScript forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
  • Campbell Ritchie
  • Bear Bibeault
  • Ron McLeod
  • Jeanne Boyarsky
  • Paul Clapham
  • Tim Cooke
  • Liutauras Vilda
  • Junilu Lacar
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Tim Holloway
  • fred rosenberger
  • salvin francis
  • Piet Souris
  • Frits Walraven
  • Carey Brown

modification of db.db

Posts: 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I am currently completing the FBNS assignment and reading the instructions from Sun, I have found a couple of issues which I can�t seem to figure out myself.
1: Describing the db.db file, the instructions say

You may not modify this file, but you may move it if you wish.

Does this mean that I am not allowed to change the "Available seats" attribute for a record when I book a seat, or does it (only) mean that I am not allowed to change the structure of the file?
1.1: My initial implementation can book flights on one of the 24 provided flights by changing the "Available seats" attribute for a record in the db.db file. BUT if I am not allowed to change the db.db, I will have to make a new db-file and use the db.db as a sort of flight schedule. My new db will then have a schema that looks something like [Flight num][Available seats]. Introducing a new db-file is something I would like to avoid if possible.
1.1.1: If I have to introduce a new db-file, I might as well add a Date attribute so that I using db.db a schedule, can book a flight on a specific date not "just" "2 seats on SA001 on Monday" but "2 seats on SA001 on 06.01.2003". This is probably more realistic, but is it necessary?
I hope you can help me with your thoughts on these considerations.

Posts: 1872
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Tejs,
I feel the same sort of fright about many of the "must-be" injunctions in my own assignement (URLyBird) : if, after a search for the coupled words "automatic" and "failures", you re-read the whole assignment, well you can get afraid, indeed ... :-)
I cannot answer for sure in your case because I have a different assignment. But by re-reading the whole assignment doc and using some common sense, I think that such a question brings the right answer : if you have only one database file (as in the URLyBird assignment), it doesn't make any sense to keep it read-only... So the "you may not modify this file" instruction should mean that you cannot bring any structural change to the file.
Warning : In my own assignement, in the packaging section, I got a related "must-be-or-fail" instruction :

The original, unchanged database file that was supplied to you. Note that you must keep a copy of the original database file supplied to you, and this must be the file you submit. The marking process will expect the exact same data without any changes.

If it's applicable for you, make sure you upload the original file and not the one you used for testing.
Ranch Hand
Posts: 117
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I think a reasonable interpretation of the instructions is that you may not alter the structure of the datafile, but you may alter the values of the fields in the file.
If you were unable to alter the fields' values then you would be unable to make bookings.
When I did my assignment, I kept the original db.db file aside (remember, part of your instructions say that you have to resubmit all the original files sent with your assignment), and used a copy in a directory called "data" for testing and running the application.
I just found out today that I passed, so the examiner can't have had any probem with my approach
I think you already answered your second question. It seems like the unnecessary introduction of complexity, and that could create scope for losing marks.
Forget this weirdo. You guys wanna see something really neat? I just have to take off my shoe .... (hint: it's a tiny ad)
Thread Boost feature
    Bookmark Topic Watch Topic
  • New Topic