That can only be due to the script trying to open a non existing file so either the CSV is being copied to the wrong folder or the named is incorrect. Check the following items:
A hex editor (e.g. WinHex, Neo Hex Editor) can be used to change it at offset 0xFC. Be aware that it's going to be displayed in hexadecimal so a calculator may have to be used here.
Look up the offset in FXTHeader.mqh, which is displayed next to each setting. Use a hex editor. Note that all values are in little Indian format, meaning that if a value that exceeds one byte it has to be filled in the bytes to its right, e.g. to write 300 in the file it will have to be written as 2C 01.
This is common with Windows 7 / Windows Vista when running MT4 from Program Files folder. The issue is as the UAC is enabled and these operating systems use folder virtualization. In Windows 7, the resulting files can be found in c:\ProgramData\ typically, while in Windows Vista they can be found in c:\Users\username\AppData\Local\VirtualStore\Program Files\. If they're not there, just search for *.FXT, they have to be somewhere. To work around this issue, either copy the MT4 folder in a location not protected by UAC (e.g. the Desktop) or simply disable UAC; by typing UAC in the start->search box thing and follow the on-screen steps.
This might be due to the lack of a MIN_LOT and LOT_STEP for the symbol in the resulted FXT file. This occurs when creating the FXT file with a MT4 client while not connected to the broker on the script launching. As mentioned, the terminal should be connected to the broker on generating an FXT file.
This is common due to either failing to select a delimiter or selecting a dot (.) as the delimiter, so the solution is simply by going back to JForex, selecting comma (,) as the delimiter and exporting the CSV once again. This should be much faster than the first time as the data is now cached. You may take another look at the JForex Downloading Guide, for more details about other parameters.
Yes. Duplicate information and even the JForex header line will be disregarded by the CSV2FXT script if it is encountered in the middle of the CSV file.
If JForex is involved, the CSV file start time must be from when the older CSV file ends. The new CSV file header row can be deleted before concatenating, even this step can be skipped while the CSV2FXT script will skip that line and reveals a warning concerning that in the experts log. By finishing the export, simply append the new CSV to the older one.
If the PHP scripts are involved, stopping the processing at a month end is perfect. The processing script automatically appends to an existing file so by resuming from the start of the next month the CSV will be perfect. Yet, the processing could be stopped even during the month; for instance, if a file is named EURUSD.csv and ends on 19.03.2012, by appending data starting from 01.03.2013 and ending with 02.04.2013 (e.g. by typing php process_dukascopy_data.php EURUSD 201303 201305 EURUSD.csv), the new data will be appended to the existing CSV and the data between 01.03 and 19.03 will be in the CSV twice. In which case, about 20 errors will be added by the CSV2FXT script will to the log and an alert about older ticks will be expelled, but it is more logical to skip the duplicated data so the resulting FXT should be fully consistent, although it will take a little bit longer while skipping the duplicated period.
It's mostly due to exporting the CSV file by JForex with failure to select the comma (,) as the field delimiter as mentioned in the guide. As for some reason that grasping the default JForex setting is to use a space as field separator and put several commas at the end of each line, the CSV file is useless and has to be regenerated. Fortunately the JForex caches the data so there is no need to wait for the download once more.
It should be noted if this change is made, that the bar count displayed in the results will be wrong Ã¢ it could be changed too but there isn't much point as it has no effect on the backtest.
The answer is really the same as for question #2 above.
This means that MT4's refuses to overwrite an FXT file which is set read-only.
Because the FXT being used was created with an older script. It doesn't matter, even you can safely ignore it.
This means that the obtained results were not profitable.However, if you want to see them, select the Optimization Results tab, right click inside it and deselect "Skip Useless Results".
This occurs just when backtesting EAs that need the Metatrader 4 terminal to be connected to the broker such as Wallstreet Forex Robot or FAP Turbo. Simply, as the FXT is already there, the backtest starts too fast. This can be solved only by adding an artificial delay through the Configuration program installed with the Tick Data Suite, by increasing the backtest delay factor to something like 3. This will give a sensible enough delay with the backtest start for the terminal to be connected to the broker. If not resolved as such increase it to something like 10, and once it's done with that particular EA set it back to 0 unless you want to keep a permanent delay on backtesting or optimizing with tick data. Be aware that this will have no effect on already running Metatrader 4 terminals, so the need to be started first to take advantage of this option.
This is as real spread is used on creating the FXT. Enabling this option will cause the spread to be stored in the volume field. If the strategy makes use of the volume number, simply the number of ticks in MT4, fixed spread is needed to be used or other strategies such as counting the number of ticks and storing it in an array should be employed.
Two reasons are possible:
This is a typically occurring issue due to using the Birt's patch script and in this condition two possible causes are suggested:
If none of the above is the cause, you should first try to backtest the MACD EA using the same FXT, if stopped at the same point, there might be an issue in that range of the source CSV and the log of the CSV2FXT script could give you a description of any potential errors.
This just occurs when a start / end date is being used for the optimization. Unfortunately, this is a bug in Metatrader 4; only the first pass of an optimization uses the selected start and end date; subsequent runs use the available full range in the FXT.
When using the parameters for one of the optimization results, and to get the same outcome when backtesting, an FXT spanning exactly the period that needed to be optimized for can be used, or alternatively Use date can be simply be disabled when running the backtest for the selected optimization results; if it's not the parameters for the first run, that is.