Home » Archives » February 2004 » IMCS.CPanel.DataTransfer Module

[ Previous entry: Foxpro and CSharp ]
[ Next entry: Meet IKIA ]
02/23/2004:

IMCS.CPanel.DataTransfer Module


02:08AM.

Unholy hour for some... but for me this is the holiest of holy hours. Every thing's calm and at peace and I can code the way I want. Of course there are those times (especially when the sun is up) when I would prefer coding when U2, Paul Oakenfold, Enigma, NIN or even the soulful music of ColdPlay pounds in my ears... but when the sun decides to dream, I prefer silence.

Ah... enough of these things. I did promise myself to concentrate on work blogs once more. To discuss more programming/freelancing/system-analysis-related issues and insights would be the priority. The info-links you used to see will still be there, probably underneath each 'work blog'.

So what have I been working on for the past few hours?

IMCS.CPanel.DataTransferModule

What in wakahalarovha's name is that?

IMCS stands for Integrated Media Center System and CPanel for Control Panel. Like most control panels you see in this world, this module aims to give the user the 'lowest level access' to some core parts of the program. Most settings and configuration are in there.

One of my measurements on how 'good' a program/system is, lies on how it can stand alone independent of the programmer who created it. If it can run for 7 years or more without my intervention, the hacker-part of this soul would be lust-ified.

That is why the CPanel is there.

Of course certain 'outside factors' like operating system variables, upgrades, environment, meteorites, non-thinking management and millions of other factors, pose a great challenge to that 'independence'. Include some marketing related factors too. But, that would be another blog for now.

It has been my practice too, to make the database systems I develop compatible with a certain client's other existing database applications. And since the Registrar and Cashiering (which involves different student information-related modules) are already handled in four of my clients by another software development company years before me, I made the Transfer Module as a means to export their databases to my database applications.

Of course I could make use of their database directly inside their own folders, but I prefer using my own re-structured database for a number of reasons.

One's to be safe. If something happens on their part of the application, the database applications I am maintaining would not be affected. Same holds true the other way around. If corruption or any variation of those things happen, their system would not suffer.

And trust me when I say I don't want a fellow Foxpro programmer to suffer... especially in my own hands.

Second reason is I am very particular with how I name the fields, the name formats and such. If you maintain several programs, it would be good for you if you're using your own easy-to-remember conventions which would be hassle-free for you to recall once you switch on your development process to and fro from within your tasks pool.

Third reason involves the way I normalize fields and records. Fields such as Relative01, Relative02, Relative03 and so on is a big no no for me. Well, at least most of the time. This would be a different story though if it is a RelativeGivingOutiPodsandG5sToDevelopers. If this is the case... the more the merrier applies instead.

But following a database system that is not yours is not that easy. Even if both systems are developed in Visual Foxpro and you're only scratching the database parts.

For one, the other database programmer can change the structure of the database at any point, and you, like me, find yourself re-coding some parts of your program, which in my case, the Data Transfer module.

These occur too especially if the other software development company has more than one programmer who seems to juggle with their field naming convention. CLIENT_01 uses MTELNO and FTELNO for their parent's phone numbers. CLIENT_02 on the other hand uses MBTELNO and FBTELNO where I suppose 'B' stands for Business. Client_01 don't have equivalent names for those fields. And in this digital world, one bit makes a BIG difference.

Last June, I also found myself in a position where another database structure was change and I cannot even edit it until I open the database exclusively. A feature which I should be adding on the Database Utility Module (equivalent to Clipper's DBU) I made.

A utility which I will discuss further in another blog... in another time.

иии

Good luck, Arctic Team... may you find what you've been looking for. Same shout outs to Cassini and the Mercury Messenger as well (472 million dollars for 7.9 billion kilometer journey eh?).

Aloe vera may treat battle wounds. Nah... I prefer peace, unity and discussion. Deal with things the way 'good' programmers handle problems. War was never a solution... and never will it be. How come we never learn from the past?

Make way for Doom's Day instead.

Mark Anthony Panizales is now bloggin'... and Ceazar Ryan Sealana too. If you could remember they were part of the first call-to-blog post of mine. I'll be posting a second batch of roll calls within the week.

Looks like SCO gets it.

I don't get it.

Nevermind.

Happy birthday, Neil Armstrong.


Disclaimers are for castrated EARTHLINGS.
Powered: GREYMatter | GM-RSS

 

 
 
 
 

 

foxpro.main
foxpro.archives
richardbase.home

articles
downloads
snippets
utilities
knowledgebase.links
website.links

outpost.forum
the.site
the.catalyst
pixelcatalyst.lair

rss.feeds

February 2004
SMTWTFS
   1234
567891011
12131415161718
19202122232425
26272829   
February 2006
January 2006
December 2005
November 2005
October 2005
September 2005
August 2005
July 2005
June 2005
May 2005
April 2005
March 2005
February 2005
January 2005
December 2004
November 2004
October 2004
September 2004
August 2004
July 2004
June 2004
May 2004
April 2004
March 2004
February 2004





GEEK count:
visitors since the aliens rebooted the counter last 02.23.2006 (was around 33,000++ before the alien intrusion | SINCE: 02.26.2004)