Tomasz, Thx for the reply. I'm a little confused. It appears that as long as esignal is delivering intraday data instead of historical data, the daily chart seems to compress the intraday data for display on the daily chart (not a native EOD record), and assigns a timestamp that is equal to the start time of my time filter as defined in the database. (in my case, it's 9:30am). In the quote editor on the esignal instance, there are no datetime values where the time is blank (i.e. EOD) for quotes where there exists intraday data for that day. So using esignal/local database by itself, I'm not seeing the interleaved data in the AB database as you describe it below.
It would appear to me that in the stage whereby I take this esignal data from the local database on a daily chart and populate a table for a symbol that does not yet exist, all the EOD record timestamps will be 00:00:00, which makes sense. However, it appears that because esignal doesn't populate the local AB database with EOD records for every day as long as they continue to provide intraday data, that I must check to see if the timestamp is something other than 00:00:00 (implying an intraday compressed daily bar), and change it to 00:00:00 (e.g. from 9:30am) on the way out to the SQL database, thereby converting the compressed daily candle into an EOD record in my SQL table. This implies stage 1 of my data export to SQL starts with a daily chart, and not a 1m chart. That would solve the 9:30am data corruption I mentioned below.... Now, what you must talking about below is a situation where the data *in the AB local database*, if it were to be interleaved (something I find no native evidence of as far as esignal goes), that the Monday EOD data must follow the monday_intraday data. From a chronological perspective, it makes sense that you can't have EOD data until the end of intraday data (obviously). I can easily put in code to hold off creating an EOD record in the table for the current day until the intraday data is done coming in. However, where I'm confused is as follows: The SQL query you're using in the ODBC plugin will deliver quotes to AB in ascending datetime order. Therefore, if interleaved EOD and intraday data were to exist in the SQL database, regardless of how it's stored in the SQL table, it will always be delivered in the order of Monday_EOD *before* Monday_Intraday, because, for instance, 2009-03-30 00:00:00 which implies *todays* EOD record because of the date portion is that of today, would be delivered to AB before the intraday data. If I were to convert all the compressed 9:30AM timestamps on the daily chart upload to 00:00:00 on the way into the SQL table (as mentioned above), I'd have an EOD record in the SQL database where esignal doesn't have one yet. If in a second stage I switched to 1m esignal data, and fed that into the same SQL table, I'd have the interleaved (mixed data) scenario. What you're saying below implies that Monday_EOD data actually has Tuesday's date with 00:00:00 timestamp. From what I can tell in the ODBC plugin source, I see no evidence that that is the case. It appears to take the current date, and convert 00:00:00 to 31:63:15 to tell the receiving AB database that this date is an EOD record. Therefore it doesn't appear to me that mixed interleaved data would ever appear in the order you state below in the AB database when using the ODBC plugin, unless you're emphatically stating that every EOD source record has the datetime where the date portion has the date of the *following* day but is somehow translated into the date of the previous day. Please clarify whether this is the case, because from what I can tell, EOD records are delivered by the query to AB *before* intraday data, not after it, and that only by virtue of the ODBC plugin converting 00's to 31:63:15 (I think that's actually what it is) in the timestamp does it end up after the intraday data in the AB database.... which is something you seem to be managing internally, so I'm really not sure why you'd mention it... hence the confusion. -Dan --- In [email protected], "Tomasz Janeczko" <gro...@...> wrote: > > You need to populate in datetime stamp increasing order. > Therefore single EOD record (hour=15, min=31, tick=15) comes > after intraday records for given day. > And all that chronological by date. > So: > > <MONDAY_INTRADAY><MONDAY_EOD><TUESDAY_INTRADAY><TUESDAY_EOD><WEDNESDAY_INTRADAY><WEDNESDAY_EOD> > > and so on. > > > Best regards, > Tomasz Janeczko > amibroker.com > ----- Original Message ----- > From: "ccr1der" <d...@...> > To: <[email protected]> > Sent: Monday, March 30, 2009 9:48 AM > Subject: [amibroker] Re: Populating MS SQL database with data from esignal - > prob solved > > > > OK, so after remming out that one line in the ODBC source code, a 1 min > > mixed database now correctly displays both intraday and > > daily candles. > > At this point, there's a small gotcha whereby intraday data needs to be > > populated first, followed by daily data, to prevent a > > scenario where the populator takes consolidated 1m data, turns it into a > > daily candle with a 9:30am timestamp, and trumps the > > actual 1m candle 9:30 data. > > > > Basically preventing a somewhat corrupt database for intraday purposes. > > > > I can see I'm going to have to add some significant code to manage the > > conversion/consolidation of intraday data into EOD data on > > a regular basis, but it looks like I've got a working solution for the > > moment. > > > > My only dream would be if a better coder than I could add a "PutArray" > > and/or "UpdateArray" function to the ODBC code. > > > > Thanks to all for enduring my rants on the topic, and to TJ and the gang > > for such an awesomely extensible TA platform. > > > > -Dan
