1

I have a Unix script which is called by a scheduler (CTRL M) every 3 seconds. The script queries an external database(not belonging to my application and therefore I can only query it) to check for new records. Currently it stores the last run timestamp in a local table and on the next poll queries the external database for all records > timestamp. Now I want to avoid updating and querying this local table. The only option I see is to store and read this timestamp in a file.However chances of the file getting corrupted or overriden are higher than data in a database. Google had lot of java options but I need this in a script.

Is there any better way to store the timestamp or better design for the functionality as a whole?

  • 1
    Why do you think storing the timestamp in a file is more vulnerable for corruption and what actual problems do you have with your current solution of using a database? – Bart van Ingen Schenau Sep 6 '14 at 6:48
  • Some shells (fish, ksh...) support global environment variables. If that's a possibility for you, consider setting the latest timestamp in a global environment variable at the end of the script, and having the script consult the variable when it next runs. If this isn't an option or you need more ideas, try unix.stackexchange.com. – Reg Edit Sep 6 '14 at 10:28
  • @Bart-Many other processes are polling the same table and I was asked to stop querying this table repeatedly. Also I just thought the file could be overridden by someone say releasing incorrect files to the Production box or may be disk space full , but I see your point , as these could apply to database also. Good to know that this could be OK for a Production environment. – Plaiska Sep 6 '14 at 13:08
  • @regedit - Didn't know that dynamic values could be available in global variables after scripts end,will check it out. – Plaiska Sep 6 '14 at 13:12

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.