Yofi,  Thanks for the quick response.

--- In [email protected], "Yofa" <jtoth...@...> wrote:
>
> Hi,
> 
> Does the 2nd instance of AB use a daily or intraday database? If it is 
> intraday it looks for time as well.
> 
> Also notice that you may end up having the same records many times in your 
> database tables. There is no logic in your code to select only the "new 
> bars".
> 
> Y

The 2nd instance of AB is using 1 minute database, which is the same as 
instance #1 (aka the esignal -> SQL populator).
Instance #1 configured for esignal feed with local database is able to 
delineate daily data from intraday data on the fly with no issue..
Instance #2, configured for SQL data (no local database), is NOT able to 
delineate daily data from intraday data, and it would appear there is no way to 
do so currently from a single table.  EOD data ends up with a 00:00:00.000 
timestamp in the SQL database, and AB thinks this is an intraday record with a 
midnight timestamp, and doesn't display what should be EOD data when "show 24 
hours trading" is not enabled.

In the SQL DB, the SYMBOL and DATE columns are a clustered primary key (the 
combination of which are unique for every row).
Therefore, there is no issue with my code and duplicate records.  Attempts to 
add duplicate records are simply rejected.
I do plan to add code to detect the last bar's datetime in the SQL database and 
only try to add new records so as to speed up the population process. But for 
now, the clustered primary key solves that issue.

I'd be perfectly willing to maintain 2 separate tables, one for EOD data, one 
for intraday data, but there appears to be no seamless way to switch between 
data tables on a per chart interval basis.
Several people specifically noted this lack of functionality in a recent 
Amibroker feedback entry, which was very prematurely dismissed and closed as if 
the functionality already exists
(read the manual, watch the floating chart/symbol linking video, yada yada... 
that has nothing to do with the issue at all).  Several people noted this lack 
of functionality as a significant
roadblock, and now I'm hitting that wall too.

I'm just looking for the behavior of a mixed EOD/Intraday database that I can 
do with esignal to exist for the ODBC plugin.
Without some method of delineating EOD from Intraday in the same table, or some 
way to source data on the fly from 2 different tables, depending on what the 
chart interval calls for,
use of the ODBC datafeed plugin appears severely crippled and virtually 
worthless, unless I'm willing to run completely separate instances of AB for 
EOD and Intraday (I'm not).
That is a horrible kludge for a problem that doesn't exist for non-ODBC 
datafeed combo's like esignal/local database.

The datetime data type constraints obviously don't allow for the timestamp to 
be blank in the SQL database.
It would appear that the local database doesn't force the datetime data type 
constraint, allowing for a blank timestamp implying an EOD data record.
However, the datetime data type in MSSQL does allow for seconds and 
microseconds.  Granted, I know AB doesn't timestamp with seconds and 
microseconds, but perhaps the seconds and microseconds area of the datetime 
field could be used to delineate EOD from intraday data in the same table.
I could easily put code in the populator to set the timestamp to 00:00:00.999 
for an EOD bar, and if the ODBC datafeed plugin and/or AB had functionality to 
see the .999 and say "this is an EOD record" that might be one solution.

Bottom line, I'm just looking for the type of seamless functionality/behavior 
of the mixed EOD/Intraday database I have with esignal feed to work the same 
way on the SQL fed AB instance.
Either some automatic way to source daily and intraday from 2 separate tables 
on the fly as needed, or some trigger in the timestamp that helps AB 
automatically delineate EOD from intraday data in a mixed table (my personal 
preference).

Without one or the other, the ODBC data feed plugin is probably rendered 
unusable to all those unwilling to completely change the way they work by 
having to maintain 2 completely different AB instances /work modalities for EOD 
and Intraday use.  

Any ideas Yofi?  Anyone?

-Dan

Reply via email to