A ProDataSet definition should represent the appropriate internal representation of your application data, that is, how the application should view and manage the data. This can vary considerably from the way the data is actually stored in your database or other sources of data. You can use the ProDataSet as a way to mask the actual data structure and even the nature of the data source. The term data source written in this way is intended to be generic and can refer to any source at all. It could be an OpenEdge database, another database, a flat file, a stream of data coming from a scanning device, or anything else. By contrast, the term Data-Source refers to the specific ABL object that maps an OpenEdge database buffer or query to a ProDataSet buffer. You can use your own FILL logic to populate a ProDataSet from a non-database source or when the buffer and field mapping provided for it is not sufficient to define the data transformation to get the data from how it is represented externally to how it should be represented within the application. The goal is to free up your application logic from being constrained by the physical reality of your database definition. By defining ProDataSets that present your data to the rest of the application as you want it to be seen, you can greatly simplify the logic that handles that data. By properly separating out the logic that maps the external to the internal form, you allow yourself to change the external form as you need to, and then simply change the code that does the transformation. This lets you gradually clean up an older database that might have an inferior design, without changing all your application logic. Or, it lets you substitute an entirely different source for the same data without the application knowing or caring. This is the notion of the data access layer that we are introducing here.
