The Problem

We are seeing intermittent problems with imports, and have made changes to the export routines in order to resolve these intermittent problems.

In brief, the student records and the standards that are exported have traditionally used a format for the exported text in which tab markers are used to designate the boundaries between the fields into which the data is being imported. If you can visualize a huge spreadsheet, in which the first column, for example, is the students' first name, and second column the middle initials, the third column the students' last name, and the fourth column is the student's city and state. The table or spreadsheet would look like this:

Johnny	J.	Jones	Anaheim, IA
Susan	B.	Smith	Pasadena, IA
PauL	(NMI)	McCartney	London, IA

The text file that carries this exported data for import to a different copy of the EIEP looks something like this:

Johnny (tab marker) J. (tab marker) Jones(tab marker)Anaheim, IA
Susan (tab marker) B. (tab marker) Smith(tab marker)Pasadena, IA
Paul (tab marker)(NMI)(tab marker)McCartney(tab marker)London, IA

Characters other than tab markers can be used to denote the boundaries between fields. Commas, for example, are commonly used.

If, for some reason, at the time of import the tab markers are not recognized as marking field boundaries, and the system is instead looking for commas, then all the data up to the first comma is imported into the first field. In other words, in the example above, the student's first name, middle initial, last name, and city will all be imported into the "first name" field. The state, "IA", will be imported into the "middle initial" field. Nothing would be imported into the third and fourth fields. It would look something like this:

JohnnyJ.JonesAnaheim	IA
SusanB.SmithPasadena	IA
PauL(NMI)McCartneyLondon	IA

Another example is in the "standards" database. There are only two types of information in this database: the number of the standard and the text describing the standard. For example, a typical export from the standards database that used tab markers to denote field boundaries would look like this:

II-A-1-a	Demonstrates respect, tolerance, and acceptance of the diversity of others.
II-A-1-b	Listens, reflects, and responds appropriately to the comments of others.

The exported text file would look something like this:

II-A-1-a(tab marker)Demonstrates respect, tolerance, and acceptance of the diversity of others.
II-A-1-b(tab marker)Listens, reflects, and responds appropriately to the comments of others.

If the system looked at commas instead of using the tab markers as intended when importing this information, the result would look like this, with everything after the second comma truncated, or perhaps even imported into the next line on the table:

II-A-1-aDemonstrates respect	tolerance
and acceptance of the diversity of others.
II-A-1-bListens	reflects
and responds appropriately to the comments of others.

We are finding that sometimes the data is being improperly imported, as in the examples above. This can produce very strange-looking data. In the IEP database, for example, the first field is the "additional information" field. If there is a lot of text, such as a long report, in that field for a given IEP that's being imported, everything up to the first comma in the report will go into the additional information field, everything up to the next comma will go into the next field in the list, and so on. The problem is intermittent, so we have not yet been able to identify the causative factors. We have made changes to the EIEP system that should prevent its occurrence in data exported from the new version of the EIEP, but exports from older versions may sometimes be imported in this way.

The Solution(s)

Sorry, there aren't any. (Just kidding.)

Actually, there are a few solutions, but none of them is terribly satisfactory. What seems to work best is to use a spreadsheet or database program, such as Microsoft Excel, to import each of the exported text files and then export or save them as text files, in comma-delimited rather than tab-separated format. Be sure to give each set of data the same name as the original text document.

Another option would be to import each of the text files as ASCII into an AppleWorks database, and save it as a comma-delimited Mac text file via MacLinkPlus.

If this is something you feel is beyond your level of "exportise," so to speak, a lower-tech solution might be to try importing the text files that are problematic on your computer ("Computer A") into a copy of the EIEP that's on a different computer ("Computer B"). The second system may recognize the tab markers. If so, you can then export the student records you just imported from the EIEP system on Computer B, and try importing the new set of exported text files into the original EIEP system on Computer A.

A third option, that can be used only with the standards database, and only if you have FileMaker expertise, would be to export the data manually, as a FileMaker-formatted file. Please note that this strategy will not work for the export and import of student records, since more than one database is involved when importing student records; calculations must be performed as part of the import process that are necessary for the related data to "stick" together, with IEPs knowing what students they belong to, and goals and services knowing what IEPs they belong to.

The fourth option, then, would be to put your five export files into a folder, zip or stuff the folder into a single archived file, send it as an e-mail attachment to your EIEP tech support person, and let him or her worry about how to fix it. :)

Thanks to Dennis Sychra, Dennison Schools, for his input to the development of these instructions. (The webmaster takes all responsibility for any jokes the reader does not find humorous.)