Local database table

I want to save position information about various strategies in a table like format. So that one column will be strategy name, second column ticker, third column position, fourth column a string comprised of order ids for limit orders sent to the market that hasn't been filled yet. I want this information to be not forgotten when amibroker shut downs. In python I can do this simply by saving a pandas dataframe to the harddrive and then later on reading it and finding the row corresponding to a particular strategy to get information, make changes etc. What's a good way of doing something similar in formula language? Should I write into a csv file and read it back?

Possibilities for non time series data:

  1. Saving to text file (.CSV, .TXT, ..) and using AFL file functions
  2. Persistent variables (via StaticVar* functions)
  3. Osaka Plugin
  4. AmiBroker ODBC plugin (SQL, MySQL etc).
  5. AmiBroker Notepad with Note* functions
  6. Also there is AmiBroker Python plugin (search AmiPy)

Ok, I will try to use the native AFL functionality first. But I am having difficulty figuring out where to start the search. What's the name of a data structure to save this type of information (in python there's dataframes for example). Also, what is the name of the function that I can use to save this data structure? Or do I need to save each item on the table one by one?

@pipcrawler, in AmiBroker there is no native heterogeneous structure similar to a Python dataframe with the support of mixed strings and numbers in tabular form.

Here is my view about some of the possibilities indicated in the previous answer.


Using the low-level file writing and reading functions you can create files in .csv format but in practice, you have to write all the code to generate them, load them, search the file, etc.

A step forward is represented by the Osaka plugin which allows you to save and read data in tabular form (strings and numbers) but does not have advanced search functions using keys/indexes; it comes with C++ sources and a good programmer could add any missing function.

But for data structures in tabular form, which can be easily consulted even outside of Amibroker, probably the best approach is to use an SQL database through the specific ODBC/SQL AFL plugin. (I would probably use this solution).

If you are an experienced Python user, it might be worth testing the AmyPy plugin to see if you can implement your ideas using familiar data structures (currently the plugin is still in beta, and it's free - in the future, it may not be anymore).

In addition to the above, you could also use AmiBroker's OLE features to communicate with Excel but maybe it could be a bit too cumbersome (search the forum for some examples).

Another pretty fancy - overkill - possibility (local or remote): if you have some web development experience, write a web server/REST API with a SQL/NoSQL database backend (for example using Django in Python) and use the AmiBroker internet functions to access it.
Hosting it on an external provider or cloud will allow you to share your custom database table between multiple AB instances (like at work, at home, etc).

(Use this link to see the complete categorized list of functions available in AmiBroker)

Of course, you could also adopt mixed solutions, for example by creating the tables externally to AmiBroker in Python and just using them from AB by reading the files (saved as .csv) or directly through the Python plugin.

Each of the indicated solutions has advantages and disadvantages.
I suggest you search the forum for discussions related to the various methods to get an idea of ​​which is the most practical way to use according to your needs.

Happy experimentation!


I'm smelling a bit of BS up there.

function vgSetTable( tablename, i, j, input ) {
	var_name = tablename + StrFormat( "%05.0f%05.0f", i, j );
	if ( typeof(input) == "number" )	VarSet( var_name, input );
	else if ( typeof(input) == "string" )	VarSetText( var_name, input );
	else	Error("Input type has to be number or string");

function vgGetTable( tablename, i, j ) {
	var_name = tablename + StrFormat( "%05.0f%05.0f", i, j );
	return VarGet( var_name );

What you get is a table of mixed types string or number.


@fxshrat I agree: the term "native" in my post is a little misleading.

I should have said more precisely that, excluding plugins, there is no comparable evolved data structure immediately ready to be used (as in the case of a dataframe in Python through the use of dedicated library like pandas).

On the other hand, it is well known that a gifted programmer can practically write almost anything in AmiBroker!


@beppe - dataframe IS NOT NATIVE in Python.
It is provided by Pandas.
Pandas is an add-on library. As pretty much anything usable in Python is add-on library.
In AFL the equivalent of library is a plugin. You have plugins that extend AFL. There are libraries / plugins in AFL that allow what original poster asked for (namely ODBC, Osaka).

So your comment that Python has that "native" is incorrect because dataframe type IS NOT "native" in Python. It is provided by 3rd party add-on.

Saying that dateframe is native in Python is equivalent to saying that OpenGL is "native" in C. No, it isn't. It is an add-on library.

It is pointless to put everything under the sun into the language. Language is supposed to be small. In "C" even printf() is NOT NATIVE. It is part of stdio library.


Yes, I think I managed to make python plug in work. Thank you for giving many other different possibilities. I just need to write some functions in python to search and insert into a data frame so I can call them from amibroker.

1 Like

This topic was automatically closed 100 days after the last reply. New replies are no longer allowed.