We can't tell "what format" that is in: we have no idea what the data is supposed to be, or how it is generated.
So you need to start with the app that generates the "final file" and use teh debugger to look at four things:
1) The input values it is actually using. Not the values in the "a, b, and c" files, or the values in the DB, but the actual values the app is using to create the file "d".
2) How it combines those values to produce a file.
3) The output values it actually generates. This probably means using a Hex editor to look at the data as byte / binary values rather than character based. (I use
PSPad[
^] - it's a good general developers text editor and works well with binary files - it's freeware). Text editors like Notepad don't help here, as they interpret some values as control characters or as "invisible" values.
4) The output values you expect "d" to contain.
We can't see any of that: we have no access to your input data, db or the "a, b, and c" files; no access to your source code; no access to your output data; no idea what you expected.
So, it's going to be up to you.
Fortunately, you have a tool available to you which will help you find out what is going on: the debugger. How you use it depends on your compiler system, but a quick Google for the name of your IDE and "debugger" should give you the info you need.
Put a breakpoint on the first line in the function, and run your code through the debugger. Then look at your code, and at your data and work out what should happen manually. Then single step each line checking that what you expected to happen is exactly what did. When it isn't, that's when you have a problem, and you can back-track (or run it again and look more closely) to find out why.
Sorry, but we can't do that for you - time for you to learn a new (and very, very useful) skill: debugging!
Quote:
1) The input values it is actually using. Not the values in the "a, b, and c" files, or the values in the DB, but the actual values the app is using to create the file "d".- I tried finding out this, but failed as the file conatians values as i mentioned above
2) How it combines those values to produce a file. - the command used is :sprintf (buff, "cat %s >> %s",
file_a, file_d);
3) The output values it actually generates.
4) The output values you expect "d" to contain.
3 & 4 - some are correct and fileds are coming -ve randomly
:sigh:
1) If you don't know what values you are using - and if you can't tell me then you don't - then you can't say "it's here" at all. You need to find out information (because we can't get at it!) starting with the source and working your way through as the problem could be at any point.
2) That doesn't generate a file. It generates a string inside a char array inside you application.
#include <stdio.h>
int main()
{
printf("Hello World\n");
char buff[100];
char *file_a = "hello";
char *file_d = "world";
sprintf (buff, "cat %s >> %s", file_a, file_d);
printf("%s\n", buff);
return 0;
}
Will show this:
Hello World
cat hello >> world
There is nothing there that generates files!
Even if you execute that string as a system command, it's not going to do anything particularly useful if the input file_a contains binary data as
cat
treats it as text!
3) And they are?
4) Am I supposed to guess what you expect?
Look, you have a debugger - I'm damn sure you do, and even if you don't know how to use it Google does - and that is the tool you need to use to find out exactly what is going on!
We can't sort out problems for you without actual information that you have access to and we don't.
At the moment, your car has broken down in the middle of nowhere.
You called the garage - me - and told me "it don't work!"
When I ask what car it is, what happened to it, what part doesn't work, where are you - all stuff a garage needs to know to come and fix your car - you have described your keyfob: "Well it's black, and made of plastic. It's got two buttons on it and I hung my house keys on the end". That doesn't help a mechanic, and your answers don't help me.
Help us to help you!