jwcolby
jwcolby at colbyconsulting.com
Tue Jul 20 14:16:48 CDT 2010
In Access I had a system for handling what I call SysVars, which are program global variables, stored in a table, cached as the program opens. SysVar VarID - Int - surrogate key VarName - Str - name of the variable VarVal - Str - Value of the variable VarDescr - Str - description of how the variable is used VarRefresh - Bool - needs to be refreshed before use. This essentially replaces what many developers use, a single record in a table where you add a new field every time you need a new variable (yuk). Just as an example... I have an asynchronous process where I: 1) Send 2 million record chunks of data to files on disk. 2) Ship the chunk files over to a VM input directory for processing 3) Process each file, placing the processed result files in an output directory. 4) Watch the output directory for processed files and ship back to the server 5) Import the chunks back in to SQL Server. The problem is that step 3 takes about 1 hour per file. If I run this process on a large table I can export 30 files to the VM which translates into 30 hours before it finishes processing. If I get a rush order, I need to delete the files in the VM so that they are not clogging up the works and not automatically send those files back to the VM until I say so. I have a SysVar called VMHold which is a true / false, true if hold files going to the vm and false if not. I can set / reset this sysvar through a sysvars class, and it reads / writes the value to the sql server tlbSysVars, caching them in memory as the program opens, refreshing them before use ONLY if the varRefresh is true. That is what I call SysVars and how / why I use them. It seems like everyone would use these for any moderately complex asynchronous or multi-user program. I am looking for feedback on how others implement this functionality. I will write a second email regarding some of the issues I am running into. -- John W. Colby www.ColbyConsulting.com