I wrote you already: there is NO hard limit. You can set to ANY value you want and your computer can handle. The limit is the HARDWARE you have (actually RAM amount).
And I told you - it costs $4800 if you want to have it implemented your way. If you want to pay for custom programming we can discuss it. If you don't - case closed because I am not going to spend my money and time on project that is going to be used by 0.1% of customer base. Best regards, Tomasz Janeczko amibroker.com ----- Original Message ----- From: "Angelo" <[EMAIL PROTECTED]> To: <[email protected]> Sent: Friday, September 14, 2007 3:31 PM Subject: [amibroker] Re: Is 500,000 the maximum number of bars allowable in a database? > --- In [email protected], "scourt2000" <[EMAIL PROTECTED]> wrote: >> >> >> Tomasz, >> >> Just because I store large amounts of data in one file (aka, a >> symbol), it doesn't mean that Amibroker has to process all of that >> data. Take the example of sqlite, the free database stores all of > its >> information in one file but users don't process all of that data > just >> because it's in one physical file on a disk. The stock data in >> Amibroker is a simple database. >> >> Please address this point: >> >> 1. Amibroker should never delete old stock/futures data just because >> new data is coming in. All that is needed is for Amibroker to limit >> the amount of data it is willing to pull in historically from some >> specified start point in the past. Whether that is a certain number >> of bars or a specific date range, that's fine. Like I alluded to, > if >> I have 5 years worth of something like ES tick data as a continuous >> contract in one file and I want to backtest (or view) a date range > in >> that data, then I should have some way in Amibroker of specifying a >> start date and end date for the data segment to be pulled in for >> processing. >> >> Here's what Amibroker currently 'says': "I'm going to use all of > the >> data you have for a symbol. If you have too much, then I am going > to >> blow out the PC's memory. Game over." >> >> Here's what Amibroker should do: If there's too much data for a >> symbol, let the user specify a date range for testing/viewing or so >> many bars leading up to the present bar for testing/viewing. The >> actual physical size of that data on disk remains intact, just not > all >> available for processing due to memory limitations. >> > > > Hi everybody, > > just my two cents opinions: > one thing is to use AMB with historical intraday data, and, in that > case there's no problem I'm aware of. > Completely different matter is collecting real time data and storing > them for a later use, given that - for example - a "normal" day on > the emini S&P could easily exceed 60000 ticks. > > Sorry to hear from Tomasz that Steve' suggestions (reported above) > would require much time and effort. > > However, given that not every AMB user has the confidence "to touch" > the Windows registry and it is not always practical to remember that > every X days you have to save older data in order to avoid their > distruction on a FIFO basis, I would kindly suggest Tomasz to think a > bit more about this matter. > > How many more AMB users could use the software to collect real time > data, if no more work is required in order to save them all (this is > one of tha main purpose of people collecting real time data, isn't > it?)? > > I humbly feel the "ten days of projected work" should be faced with > the question above, and not with the global value of the time > required, valued on an hourly basis. > > > > > > > > Please note that this group is for discussion between users only. > > To get support from AmiBroker please send an e-mail directly to > SUPPORT {at} amibroker.com > > For NEW RELEASE ANNOUNCEMENTS and other news always check DEVLOG: > http://www.amibroker.com/devlog/ > > For other support material please check also: > http://www.amibroker.com/support.html > > Yahoo! Groups Links > > > > >
