In the ED app i am mowrking on there is 3 files containing data for my app....
[employee.xls] --> A file very simillar to the csv but it has titles and i don't know why it is there?
[employee.csv] --> the file included in the ZIP below
[employee.csv.zip] --> where the app fetch the data
Could anybody just tell me the relation between these files?!
I haven't seen the application in question, but the following is a fair bet for the reasons and the relationships...
The zip file is just a handy way of keeping the file size down (and giving you a backup in case things go wrong!).
The csv file is small and readable on anyone's system whether they have MS Office package or not - it is basically just plain text.
The Excel file has access to all the functionality of the Excel package, for example formulas but more importantly in your case an ODBC driver allowing you to treat it like a database,
I am sure that the majority can look at these files and understand but i have no clue how that works together.
I need to understand how this app sort it's data and how airSQL works because i can't seem to be allow to manually change the DB data but yet there is no logic pathern (haven't found any yet) that would explain how the app fetch its data!?!?!
I thought that by moving the col. around in the csv file i would be ok to at least find a pathern in the positioning, BUT NO!!!! let say i swap "phone number col." with "name col." in the csv.zip file.... then restart the app and find out that the country moved!??!!?? i am lost! CAN ANYBODY EXPLAIN THE RELATION WITH ALL THESE FILES AND THE DB!?!?!?
-stored data (on the picture you also have the output of this data in the app)
-.csv file [we have 3 but only one that act with the app] attached[employee.csv.zip]
then we have all the files within the app that calls, fetch or interact with these data...
employee.csv.zip 3.2 K
the easiest way to find out what files are being used is to look at the Flex code (in your case of course AIR but the same principles apply). I haven't used AIRSQL, still less this particular example, so all these comments are general principles that apply whatever the specific case. You should be able to track down from the code:
a) which files are being used as inputs - these will be called by the SQL code or (more likely) a connection string of some kind identifying what database AIR is connecting to in order to extract data. For most databases this identifies either the physical location or a logical one (physical for simple ones like Access or Excel, logical ones for more complex ones like mySQL, Oracle, SQLServer etc), together with user credentials (for Microsoft products this often borrows the Windows credentials).
b) which files are being used as outputs - you have mentioned a db file that you found in one of your user directories which sounds like a place where output is held. In many cases the output may be placed in the same place as the input, but maybe in this case the code writer has avoided doing that so you don't trash the original file by accident!
c) which files are simply there to help you manage the project - for example it is quite common to include a file which allows you to revert to an original installation if you get lost in making changes.
I wonder if at the moment, when you say you change something but it has no effect, whether you are changing some file which is not in fact used as an input to your code?
I think that some of your uncertainty at the moment is to do with using SQL, regardless of the particular situation. SQL can refer to columns by name (in which case the order of items in a spreadsheet does not matter, and in a real database you have no control over how the data is physically stored anyway), or alternatively by number (in which case the order is crucial).
The screenshots are a little too small for me to read clearly (! poor eyesight...!) but so far as I can tell:
a) top row middle is a SQL statement to create a table, probably the one you have tracked down as employeedirectoryM6.db but as batchExec is not defined within the area it is hard to tell
b) top row left is populating a Flex Employee object with values from the result of a database call (indexed by field number eg itemArr not by name)
c) bottom row left is setting up parameters for a database insertion from an Employee object, probably I imagine read from values in a GUI
d) in the lowest screenshot, the GUI design is showing you how GUI elements are bound to data from Employee objects.
Basically you have three levels - a database holding employee data in one or more tables, a GUI showing the user values for a particular employee and allowing him or her to edit them, and mediating between them some coding objects like Employee which straddle both of the above.
Hope that helps,
Definitely Helps, man at this point any answer in this forum with more then one line is considered miracle!
I will review every points you made so that i get the mapping in my head.
that's what i was assuming for the Col. DBtables relation [indexed by field number eg itemArr not by name] i did run in some wierd behaviors but i have to take in consederation the String property so that it fits the restriction because it doesn't show info if the data do not fit the String [I.E. number instead letters etc]
I am getting there...freakin' slowly but i am getting there! hehe