Hi Donald,
DP organise its data into "panels" which embody both the data structure,
user interface, link logic and application logic. Unlike most other DB's
there is no a separation of data from presentation.
The core file for an application is the .STR file. That contains definitions
for all DP stuctural elements. If you were to separately take the .STR to a
new folder and open it with DP.EXE then it will generate all the other files
(albeit without data). so you APP.STR is the main defintion file, the
App.ind holds the indexes for all panels, and the .txx is the variable
length field data files as you have already identified.
The Panel files contain the data. Each panel is given a file name by the
designer. I presume that the APP.EME and similarly named files are these
panels files, as you enter each panel it displays its filename in the info
window.
There are a number of ways to dump the data. CTRL-F5 is used to import data.
Shift F7 presents the reports menu. Te top report is always the built in
short report. By default if you use this report then it will export data
from the current panel to a file on disk, generally defaulting to the name
scratch.rep by default it exports "real fields". Fields on a panel can
either be real or calculated fields.
If you are editing a panels definition you must remove all records, the
easiest way to do this is to use the "Built in Short report" to export all
the data to the scratch.rep file, remove all the data in the panel with
Alt-F5 (be careful NOT to empty the database completely), make the changes
to the data structure, and then import back the scratch.rep using the
Ctrl-F5 import. One thing you should be aware of, is that when you export
the data it uses the EDIT order of the panel for the ordinal positions of
each data field in the export file. The Edit Order can be readily changed
from the Panel definition screen Alt-F5, Alt-F5, and the 5 to change the
edit order. Why is this so important? Because the import routine users the
ordinal position of data in the export file and matches it to the current
Edit Order, so for example if you wanted to delete a field and it happened
to be the first field in the edit order, the export file would have it as
the first field, but once you removed the field from the definition another
field will take this spot. You can change the field import mappings from the
Ctrl-F5 field but it is a pain. (If you were doing this then I would
generally make the fields you are deleting the last field in the export
file, do the export, modifications and import and you will not have a data
mismatch). If you want to just add a new field, then you should just export
the data as is, removed all the data, add the new field, export the data
back in, then change the edit order to reflect the new field you added.
When you delete data with Alt-F5 you have the option to delete subpanel
data. generally you will not want to do this.
For your problem, I would leave the original linking for the subpanel data,
by SSN, and then after adding you new Primary Key to the Main panel data,
modify the subpanel deifition to include the same field format, eg if you
were adding a G99999::IN field to the main panel, then add a G99999::N field
to the sub panel. After you have modified both panels, and imported the
data you will have the Main table with newly increment number Primary key
field, and empty field in the subpanel;. Use a report with a subreport to
write the Primary Key field to the Foreign Key field in the SubPanel. After
you have done this you can remove the Panel Link between the SSN number of
main and sub panel, and estabilish a new link between the Primary Key in the
Main panel and the Foreign Key in the Sub Panel.
You can also create reports which export data. I find this the easiest, as
you have plenty of control over the positioning, the delimiters, and you can
access linked subpanels through subreports.
Personally moving data from DP to another application I would do it as an
XML file, as the file can be self describing, and you can tranform it
readily if it is not quite right. Many other products can import the XML
directly, you need to check out the schema. and create the DP report to
accurately reflect that schema. With DP you can always export data according
to a particular schema but you are totally responsible for it, DP just
treats it as text, it itself does not have any built in concept of XML. But
this gives you a maximum amount of freedom. For instance if you follow the
schema defitions for say an Microsoft Access Database, you could create an
XML report that would export all data from the DP application, and using the
one file, import it into Access 2003, or 2007 even creating the table
structures, indexes for you. Similarly for SQL Server or MSDE, and most
other modern DBMS will allow you to import data.
Most DBMS's do not have th richness of the linking between panels. Most
relations database products only offer a subset of DP's power. You general
have to write stored procedures and triggers to get even the basic
functionality of a DP application. Consequently, when exporting to another
application, I generally find that you need to write different types of data
structures in the new application.
Good luck
Brian
----- Original Message -----
From: "Ball, Donald A Jr (Library)" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Saturday, January 05, 2008 8:08 AM
Subject: [Dataperf] Questions from a DataPerfect novice
Hi folks, I just inherited a DataPerfect HR application. It maintains a
bunch of employee data that are unfortunately keyed by social security
number. I've been tasked both with trying to replace the SSN by a
synthetic key or some sort of acrostic, and also with writing a new
version of the application using a relational database for storage.
First things first, am I interpeting the files comprising the
application properly? There seem to me:
APP.STR - metadata about the panels and fields, maybe also the reports?
APP.IND - primary key data for the panels, maybe also fixed width field
data?
APP.TXX - variable length data for the panels
then there are a bunch of APP files with arbitrary extensions, e.g.
APP.EME, which contain subpanel data, in this case, emergency contact
information. Correct so far? Am I missing any interesting files?
Dumping the data in order to bootstrap a new application seems
relatively straightforward. From each of the two main panels, I hit
CTRL-F5 and export the data in "DOS Delimited Text" format and then have
at it in the language of my choice. Problem is, there are 6 or 8 files
with the arbitrary extensions which I think contain subpanel data. How
do I dump these data? CTRL-F5 does not seem to work when focus is on a
popup subpanel.
Changing the SSN looks to be a tricky endeavor since it seems to be the
primary key for the employees table. I could certainly dump the data for
the main panel, change the SSNs in the dump, wipe out the database, and
then reimport the data, but it looks like I'd lose the subpanel data in
the process. Can anyone suggest an avenue of attack for this problem?
DP appears to be version 2.3, running on WinXP, in case that's relevant.
Thanks in advance for any tips.
- donald
_______________________________________________
Dataperf mailing list
[email protected]
http://lists.dataperfect.nl/mailman/listinfo/dataperf
_______________________________________________
Dataperf mailing list
[email protected]
http://lists.dataperfect.nl/mailman/listinfo/dataperf
