This script launches 510 simultaneous/concurrent MS-Access database SQL queries, which the database Jet Engine can handle just fine with increased Threads configured to 510, default is 3. The calling script launches the 510 instances, then immediately exits without waiting for them to complete. If you run this from a command prompt, and open Windows Task Manager, you can watch the concurrent processing occuring since I have prints to the screen going on. CPU usage will hit 100%, and my RAM memory usage hit a high of 83% for a split second, then fell back down rapidly. I have a single Intel Celeron processor 2.2GHz, and 3-GIG RAM on my WIndows 7 Home Premium Laptop. The database hit, contains a table of Bible book names: Genesis thru Revelation (66 books). 510 output files are created witht the SQL report output. I used a File Compare routine to verify all the same output. This reporting process produces reliable SQL output every time. Way to go Jet Engine!

Calling script:

use Win32; use Win32::Process; $PWD=Win32::GetCwd(); for ($i=1; $i<=510; $i++) { Win32::Process::Create($POBJ,"$PWD\\RptUtl.exe","RptUtl $i",0,DETACH +ED_PROCESS,"."); } exit;

Called script i.e. RptUtl.exe <-- compiled RptUtl.pl

use Win32::ODBC; use Win32; use IO::Handle; $i=$ARGV[0]; #-- called from another Perl script that launches 1 to +510 Windows O/S "detached" background processes. $PWD=Win32::GetCwd(); $outfile="$PWD\\BibleBooks_$i.txt"; open(OUT,"> $outfile"); OUT->autoflush(1); $USR=Win32::LoginName(); $NODE=Win32::NodeName(); print OUT "Working Directory=\n $PWD\n User=$USR Node=$NODE\n\n"; $FILEDSN="FILEDSN=$PWD\\Bible.dsn; PWD=xYz"; $db = new Win32::ODBC($FILEDSN); if (! $db) { $error = Win32::ODBC::Error(); print OUT "$error\n"; die; } $ret=$db->Sql("SELECT * FROM BibleBook"); if ($ret) { $error = Win32::ODBC::Error(); print OUT "$error\n"; die; } while ($db->FetchRow()) { my(%data) = $db->DataHash(); print OUT $data{'bk'} . " " . $data{'name'} . " " . $data{'shor +t_name'} . "\n"; print $data{'bk'} . " " . $data{'name'} . " " . $data{'short_na +me'} . "\n"; } print OUT "\nGoodbye.\n"; exit; END { if ($db) { $db->Close(); undef $db; } close(OUT); }

Contents of ODBC FILEDSN Bible.dsn which is referenced in the above code:

[[ODBC]] Threads=512 Driver=Microsoft Access Driver (*.mdb) DBQ=.\Bible.mdb

Replies are listed 'Best First'.
Re: 510 Concurrent/Simultaneous SQL Processes running on Windows O/S Laptop
by chacham (Prior) on Apr 15, 2015 at 15:54 UTC

    Side comment. In SQL, SELECT * should be limited to ad-hoc queries and EXISTS clauses. Spelling out the columns can save you from bugs and help self-document. For example, the query could be: SELECT bk. name. short_name FROM BibleBook;

Re: 510 Concurrent/Simultaneous SQL Processes running on Windows O/S Laptop
by ww (Archbishop) on Apr 15, 2015 at 18:19 UTC

    Read, absorb and use the information in Markup in the Monastery.

    Take note that entire paragraphs of thought will wrap properly if marked up with a single pair of <p>...</p> tags. Separately wrap each piece of code or data (including merely illustrative data) in <c>...</c> tags.

    The manner in which you've formatted the parent makes it un-neccessarily unwieldy to read and awkward to download... which makes you less likely to get good help, promptly.

Re: 510 Concurrent/Simultaneous SQL Processes running on Windows O/S Laptop
by FreeBeerReekingMonk (Deacon) on Apr 26, 2015 at 22:35 UTC

    Hmm.. the post seems to have been deleted. I wanted to know how this SQL story ended... while at work we have databases capable of this, however I recon a single laptop is not that powerful.

    erichansen, if you read this. Please medidate on Proverbs 3:12 Imagine you are a plant. And our replies, feel like a mountain of manure. However, 't is but fertile soil to make you grow even more (not only perl wise). In the process, we do too. I am brewing more ale, Ill set a pint aside.