From: Eric H. <eh...@co...> - 2006-02-02 15:28:09
|
The options I have thought of to correct my application are: =20 1) load the database data memo fields to an associative array at the same time I load the data to the ListView. And then populate the maintenance screen's multiline textfields (to hold the memo fields) in the ListView ItemClick event. =20 2) In the ListView ItemClick event, do a database lookup to fetch the memo fields at that time instead of Holding all record memo fields in an associative array loaded when the ListView is loaded. =20 I chose number 2. The slight drawback to this method is the slight delay when arrowing or scrolling up/down Within the ListView since the ItemClick event has to do a database lookup. The slight delay really is not Noticeable but could potentially be if network traffic or database traffic is high.=20 =20 Eric |
From: Eric H. <eh...@co...> - 2006-02-02 15:45:06
|
Here is how I populate my textfields on my maintenance screen when a user clicks a ListView item. The index to the record in the database is stored as the last column in each ListView row so I can Use it to quickly/easily lookup the database row to fetch the memo fields in their entirety.=20 =20 sub ListView_ItemClick { =20 my $ls_text=3D""; #-- ls for local scalar my $ls_ret=3D""; my $ls_error=3D""; my $ls_index=3D""; my $ls_sqltxt=3D""; my %lh_data=3D(); #-- lh for local hash =20 $gs_item =3D shift; #-- gs for global scalar =20 $ls_ret =3D Open_Database(); if ($ls_ret) {return 1;} =20 %lh_data =3D $LV->ItemInfo($gs_item,36); #-- record index =20 $ls_index =3D $lh_data{-text}; =20 =20 $ls_sqltxt=3D"SELECT Comments, [In House Comments], [Analysis Proposed Fix], Issue FROM Tracker WHERE Index =3D $ls_index";=20 =20 $ls_ret =3D $gs_db->Sql($ls_sqltxt); =20 If ($ls_ret) { $ls_error=3D$gs_db->Error(); #-- get database error = msg Close_Database(); Win32::GUI::MessageBox($W,$ls_error, "CPS Issue Tracker - Maintenance Screen - SQL Error($ls_ret)",16,); Win32::GUI::MessageBox($W,$ls_sqltxt,"CPS Issue Tracker - Maintenance Screen - SQL Cmd",16,); Win32::GUI::MessageBox($W,"Can't Get Memo Fields From Database", "CPS Issue Tracker - Maintenance Screen",64,); return 1;=20 } =20 $gs_db->FetchRow(); =20 $ls_text =3D $gs_db->Data("Comments"); $TF_Comments->Text($ls_text);=20 $ls_text =3D $gs_db->Data("Analysis Proposed Fix"); $TF_ProposedFix->Text($ls_text);=20 $ls_text =3D $gs_db->Data("In House Comments"); $TF_InHouse->Text($ls_text);=20 $ls_text =3D $gs_db->Data("Issue"); $TF_Issue->Text($ls_text);=20 =20 Close_Database(); =20 #-- additional code for the event follows but not shown here } =20 sub Open_Database() { =20 my = $ls_FILEDSN=3D"FILEDSN=3D$gs_cwd\\Tracker.dsn;PWD=3DWin32Gui102";=20 =20 #-- we don't want to show password if an error occurs so use this string as error msg my $ls_FILEDSN2=3D"FILEDSN=3D$gs_cwd\\Tracker.dsn";=20 =20 $gs_db =3D new Win32::ODBC($ls_FILEDSN);=20 =20 if (! $gs_db) { my $ls_error=3DWin32::ODBC::Error(); Win32::GUI::MessageBox($W,=20 "Can't Establish Database Connection using:\n$ls_FILEDSN2\n$ls_error",=20 "CPS Issue Tracker - Error",16,); return 1; =20 }=20 return 0; } =20 sub Close_Database() { $gs_db->Close(); =20 undef $gs_db; } =20 =20 |
From: Eric H. <eh...@co...> - 2006-02-02 16:45:26
|
Here is a great idea sent to me personally from a List Member that I wanted to post for everyone to see. =20 QUOTE: =20 One thought that you may want to consider is caching x number of values at a time. When the item changes, check the cache FIRST(in a hash based on the index number as the key), and only if you do not find the cached data, then do the DB lookup. I would do something like: =20 load listview and cache x number of values, 1->x (20 may be a good number) when an item is clicked, check the cache first for existence of the index clicked on if it is in the cache, show the data from the cache=20 else run your query to load x number of records into the cache either clearing or keeping all the existing data, depending on your expected number of items total. This depends on memory,etc. Obviously, if you will have thousands of items in the listview, you may not want to keep all the data in memory for performance reasons. =20 =20 This a) keeps memory footprint small, and b) gives quick response in "most" cases, c) reduces total database round trips. I would suggest using a temp variable to hold the NEW version of the cache until after your DB query lookup has returned. This way, if the user clicks on an item, the item is not in the cache AND the DB look up fails, you still have all the existing cached data and can have the user try again without losing the current cached values. =20 =20 In General, if you or your users would access items sequentially in "most" cases, you could also set up seperate thread to purge/load the cache in the background., say current index -20 through index +20 =20 =20 Just a thought... =20 END QUOTE=20 =20 |
From: Arthur S. <asc...@ve...> - 2006-02-03 00:34:11
|
"One thought that you may want to consider is caching x number of values at a time. When the item changes, check the cache FIRST(in a hash based on the index number as the key), and only if you do not find the cached data, then do the DB lookup. " o o o <snip> Of note is an article in the Association of Computing Machiner 1985 Computing Surveys magazine titled: Self-Organizing Linear Search pp 295 - 311 ACM Computing Surveys 1985 V17N3 It describes different means to optimize searches and includes a description of a pre-search cache of temporary values. Amortized costs are included. On a different note, the proposed but not built Burroughs B8000 contained a hardware 'cache' of frame pointers to enable quick access to objects in nested procedures. (About 1970). art |