Forum

As I mentioned before, there is no option to turn off writing to the database, so it should always be writing to the database. However there should only be one thread writing to the database, and that should be quite fast.

We don't write to $LogFile, so I'm guessing that's some Windows system thing.

I don't know how much your RAID mirroring will affect performance of the system when it needs to write data out every second. Is the mirroring handled in hardware or software?

The main problem, it seems, is that you're unable to turn off the writing to the individual files. I don't understand that since I just tested it over here.

I also don't understand why it says that there are system processes with a different PID writing the individual files to the intraday folder, since we only ever write those files directly from the main program.

Let's try this: make sure the option is unchecked, exit the software, delete the individual history files, then start the software again. Is the option still unchecked? Are the history files still being written?

It's a compound problem. Once the History checkbox has been unchecked and the blank field replaced with "intraday", you can't ever clear that field. And, apparently, PSS writes out all the files text files named for the symbols being monitored. And I deleted and rebooted, and they all came right back.

Secondly, there is a feature of UAC called Virtual Store which means that unless you have knelt humbly before the mountain and produced your application with the right kind of gold cloth, your application, when it writes out application data, isn't actually writing to where you think it is writing to. It is writing to a secret location (determined by Virtual Store). Windows will then rewrite your data to someplace, I know not where. So, you thought your application was writing to the database, but Windows was intercepting that, writing to somewhere else, and then (maybe) writing to the database.

One solution is for the user to edit the permissions to grant full rights to Everyone on the User\Username\AppData\Roaming\DTLind Software folder and the similar User\Username\AppData\Local\VirtualStore\Program Files (x86)\Personal Stock Streamer folder.

Maybe there is a way to write your applicartion to avoid the VirtualStore - I don't know. Probably requires kneeling before that mountain.

In any case, VirtualStore REALLY SLOWED THINGS DOWN. And I can't really say I've had success yet until market hours tomorrow, but at least now (having given permissions to Everyone) I don't see either those System PID's or the StockStreamer PIDs writing to the individual stock files, nor do I see but a few StockStreamer PIDs writing to the history db, nor do I see a System PID writing to the history db.

Sorry, I have to go. I think I'm getting a nosebleed (or a migraine or something). I think I'm going to go find a valium (oh, I forgot, that's illegal now), or a Xanax or something.

The checkbox is the thing that controls writing the data to the individual files, whether or not the paths are filled in. So there is really no reason to clear the field, although you can click the "..." button to set it to write the files somewhere else. If you really want to clear the field, you will find the name in the registry under HKCU\Software\DTLink Software\Personal Stock Streamer\Settings\autoexport_dir_*. (Obviously you don't want PSS running when you do this.) Also, the "autoexport" value should be set to zero.

In all my tests, if the box is unchecked, it should not be writing the individual files. I don't know why yours would be behaving differently.

I am just now able to look at this, and unfortunately, there are several hundred System threads writing to those files. Obviously, checking the box didn't reset things back. I will try editing the registry next.

Also, despite the recommendations on some forums, giving Full permissions to Everyone didn't make Virtual Store happy.

This should cause a performance problem for all Vista/W7 users, because whether they have the box checked or not, all Writes go through the Virtual Store process, which REALLY slows things down.

I thought I had success, but no. Only the database is being written to, and only by StockStreamer. Right now (3:30pm) there are more than 40 StockStremer threads writing to the db, and there is one System thread writing small amounts of data to C:\Users\Usernaame\AppData\Roaming\DTLink Software\personal Stock Streamer.

When I shut down PSS it took 57 seconds for all the StockStreamer threads to finish up and die. I can't tell what impact this sluggish I/O might be having on the application, but it probably isn't good. But, the application seemed responsive in that I could move the window around, and when I click the X to kill it, it responded right away with a dialog box asking if I wanted to save the portfolio.

I'm afraid I don't understand where all those history.db threads are coming from. We create only one database manager worker thread, and whenever something needs to be written or read from the db, it always goes through that thread. All db writes (data coming in from the streaming feed) are queued up and written in batches once per second.

Just out of curiosity, have you tried to run PSS with just one or two very active ticker symbols and see if you run into any kind of performance issues? I would expect you wouldn't, but it may be worth the experiment during market hours.

The "feature" is called User Account Control Data Redirection. You can read this:

http://windowsteamblog.com/windows/b/developers/archive...

I don't understand it all, but it seems like you might need to make some program modifications for Vista and W7. There's lot's of blogs/forums of developers griping about this, but that won't change M$.

Looking at an XP installation, it seems there shouldn't be a problem. It puts the db under C:\Documents and Settings\Username\Application Data\DTLink Software\Personal Stock Streamer, and that seems to be a legal location.

Nevertheless, as I 've demonstrated, Vitural Store has taken over.

Actually we already made those modifications a long time ago, so writes to the db file should not be virtualized. For example, on both my Vista and W7 test environments, the db file is in c:\Users\Username\AppData\Roaming\DTLink Software\Personal Stock Streamer, which is exactly where it should be. Our software asks the system for the proper app data location before creating the db file, so there should be no reason for it to be elsewhere. Where is the db file on your W7 system?