Herman, Personally, I only use AB to model with imported data - so I have no experience with the RT plugins.
Maybe Tomasz can chime in here as I, too, would like to understand how these settings work in greater detail. - Tim On Thu, Oct 8, 2009 at 1:02 PM, Herman <[email protected]> wrote: > > > Thanks Tim, regretfully it is not clear to me. > > for example DTN is a realtime data plugin but, afaik, does not keep its own > separate DB. Does changing the local setting then wipe out RT data? I use > DTN and the number of bars in my DB don't seem to be effected by any > settings. > I use my DTN RT database in local mode, for speedy AA operation, but > connect it for backfill. Since we have separate local and RT settings. How > does that work? > > Herman > > > > tr4d3rt wrote: > > Herman, > > In regards to question #1, I emailed support a week or two ago with the > same question (as I noticed that it had no effect in limiting data in a > local db). This is how Marcin explained it: > > "This setting applies to the databases operated by RT plugin, but not to > (local database). If you want to limit the size of the local database - > then > go to Tools -> Preferences -> Data, then mark "Limit number of saved > qutations" (and modify the data somehow, so the changes will be saved and > limit applied with the save operation)." > > > - Tim > > > > On Thu, Oct 8, 2009 at 9:54 AM, Herman <[email protected]> wrote: > >> For DB backups I use dated sub-folders in an AmiBrokerBackup folder. I >> don't overwrite anything, I just delete a bunch once in awhile. Disk >> space is plentiful and cheap but time is not. When backing up and >> restoring AB be aware that you can run into problems restoring if you >> backup to a different drive letter. >> >> As someone else mentioned, for processing speed I develop with my large >> RT DB set to "Local database", having the data plugin connected really >> slows down things. >> >> There are other factors to consider when working with minute DBs. A >> clear understanding of what the DB and Preference settings mean, and how >> they should be set is essential. After all these years i am still >> struggling with some points, perhaps someone can explain in layman's >> terms: >> >> 1) What does "File -> Database Settings -> Number of bars" really mean? >> It doesn't seem to set the "limit" for the data base because I can still >> have 250000 bars even if it is set to 50,000. If it refers to "Bars >> Loaded" why do we have another "Number of Bars to load" in Preferences >> -> Data ? When is it enforced, only when the DB is created or can it be >> changed for an old DB? Would this corrupt my DB? Would it reduce the DB >> in Size? >> >> 2) Is there an absolute limit to the number of bars loaded? What happens >> when you exceed the DB or Preferences setting, would it corrupt the DB? >> >> 3) How to set the In-Memory Cache size? Do we have to change this each >> time we run a different DB? Perhaps someone should design a AmiBroker >> Setup calculator :-) one of those panels you enter your system/DB >> parameters in and it tells you what settings to use. Volunteers? >> >> 4) Same question for Max. megabytes... >> >> When changing these settings, when do they take effect? >> >> I know there are ways to calculate memory usage but I create a new DB >> almost every day, I wish there was a safe default setting (XP 4GB). If >> CacheSize * NumberOfBars * 32 cannot exceed the maxMegabytes the user >> should be prevented from doing so. Or is it more complicated that that? >> >> Often when running a portfolio Backtest everything runs fine until at >> the very end (after waiting ten minutes) the Backtester gives me an >> error. I am pretty sure i am running out of memory, but this is a >> technical issue that i shouldn't have to concern myself with. >> >> herman >> >> etoketrader wrote: >> > touching on the topic of backups, I fully agree with Herman. >> > In my nightly schedule I shut down AB and copy the entire folder as >> follows: >> > >> > AB3 -> AB4 >> > AB2 -> AB3 >> > AB1 -> AB2 >> > Live Amimbroker -> AB1 >> > >> > Sounds like an overkill, but it is not the first time I had to go back >> several copies. Corrupt data is not immediately evident in many cases, >> especially when dealing with large DB's. >> > >> > BR, >> > eToke >> > >> > >> > >> > ------------------------------------ >> > >> > **** IMPORTANT PLEASE READ **** >> > This group is for the discussion between users only. >> > This is *NOT* technical support channel. >> > >> > TO GET TECHNICAL SUPPORT send an e-mail directly to >> > SUPPORT {at} amibroker.com >> > >> > TO SUBMIT SUGGESTIONS please use FEEDBACK CENTER at >> > http://www.amibroker.com/feedback/ >> > (submissions sent via other channels won't be considered) >> > >> > For NEW RELEASE ANNOUNCEMENTS and other news always check DEVLOG: >> > http://www.amibroker.com/devlog/ >> > >> > Yahoo! Groups Links >> > >> > >> > >> > >> > >> > >> >> >> ------------------------------------ >> >> **** IMPORTANT PLEASE READ **** >> This group is for the discussion between users only. >> This is *NOT* technical support channel. >> >> TO GET TECHNICAL SUPPORT send an e-mail directly to >> SUPPORT {at} amibroker.com >> >> TO SUBMIT SUGGESTIONS please use FEEDBACK CENTER at >> http://www.amibroker.com/feedback/ >> (submissions sent via other channels won't be considered) >> >> For NEW RELEASE ANNOUNCEMENTS and other news always check DEVLOG: >> http://www.amibroker.com/devlog/ >> >> Yahoo! Groups Links >> >> >> >> > > >
