Importing should be as easy as creating new

I look forward to the day that I can import a file as easily as I can create a new file.

A .csv file that contains html with

,

  • , and other characters is not bothered by the New Database from Text File menu option, but the Import Text File into Current Database just can’t handle it elegantly.

    As the user typically has no control over the contents of a .csv file, it would be a worthy feature for the Import feature to acquire the same logic that the Create New option already has.

  • Here’s how the New Database from Text File command works:

    1. It creates a new, empty database.
    2. It imports the text file into this database

    The Import Text File into Current database works the same way, but it skips step #1. But the code that brings the text into the database is exactly the same code either way.

    I’m sure you’re sceptical, but you can look at the code for yourself.

    Whatever you’re “non-elegant” issue is, it is not caused by “creating a new database” vs “importing into an existing database.” Since “non-elegant” is a completely non-specific complaint, I can’t address it in any further detail.

    Non elegant is a euphemism for ‘it does not work’. Sorry but I was trying to be kind. The HTML formatting ends up creating multiple records for a single record of data.

    This thread is a repeat of a previous request where it was found that the problem was due to tabs, returns, line feeds, etc were in the .csv file. For reasons which I don’t care to spend time thinking about, the Import choked on this while the Create did not.

    Interestingly in the interest of less coding on my part, my workaround is to Create a new db with the data, then Import that data into the desired db, then throw away the single use db. Certainly not the way it was intended but it works. It would be nice if the Import was fixed to work on data that contained non printing characters in the same way that Create does today.

    I don’t see how I could be more clear. Create and Import are not different code, it is the exact same code.

    Most likely your import has additional logic to rearrange the data as it is imported. This is probably the logic that is getting confused by your non-standard CSV file.

    Another workaround could be to create a database that has fields that exactly match the data to be imported, so that it doesn’t have to be rearranged. Import into this, then transfer that into your primary database. Basically the same as what you are doing, but instead of creating and throwing away the database every time, you would have it ready in advance. But since you’ve already got a working workaround, I probably wouldn’t bother.

    I am making zero adjustments. No additional logic. This is not being done procedurally. Just using the application menu choices. It could not be simpler when it fails.

    There is a difference between Import Text File into Current Database and New Database from Text File. One works as expected and the other does not.

    A user might figure out that they should not use Import Text File for .csv files. The workaround to create a New Database from Text File, then use that database as a file to Import Panorama Database into Current Database file, but they should not have to learn to ignore the Import Text File into Current Database option.

    Sure you do. Input data should be valid before attempting to import it. Always validate input data before using it. This is the first rule of data processing.

    • For CSV, you could visually inspect the CSV file in a text editor and make corrections.
    • You could find, buy, or write your own utility that validates and even fixes a CSV file.
    • And, lastly, you could require a valid CSV file from whomever is supplying the data to be imported.
    1 Like

    Robert sent me his text file. The problem is line breaks in his data. Line breaks are legal in CSV files (as long as the cell is quoted, which they were in Robert’s file), but they are fairly unusual. In my opinion, the assertion that import is completely broken is not justified. Yes, there is a problem with a small percentage of CSV files, probably 1-2% or even less. Very few users will ever encounter this. (Am I saying that Panorama shouldn’t be fixed to handle this case? No, of course I am not saying that.)

    When you use the Import Text File into Current Database window, Panorama is doing a lot more than just an import. This panel allows you to rearrange the fields as they are imported, even merging or splitting fields. This is the logic that is not handling line breaks within cells correctly. You started by saying that the import feature should have the “same logic” as create new, but that’s not possible because the capability is not remotely the same. So these features must have at least some separate logic, and a new fix will be needed.

    Since in your case the text file already has the same fields as the database you are importing into, you can write a one line procedure to import the text into the current database. (This example assumes the text file is in the same folder as the database.) There’s no need to go to the trouble of creating a new database and importing from it, this one line is all you need.

    importtext fileload("some file.csv")
    

    Actually, in Robert’s case he wants it to ignore the first line, which contains column titles, a slight revision will handle that:

    importtext arrayrange(binarytotext(fileload("/folder/folder/Sample product-export.csv")),2,-1,cr())
    

    Of course this code could easily be modified to allow the file to be selected with a dialog, using the choosefiledialog statement.

    If you’re wondering why Panorama doesn’t have this code built in as a menu item, I believe this case is a rare one. Besides, once the Import Text File into Current Database feature is fixed, this special case code would never be needed.