I can't reliably get a range of cells from a spreadsheet to paste into a map and generate attributes

Sometimes it works, sometimes the headers aren’t converted to attributes, and I get one large note. I’ve tried using Numbers, Excel, CSV, TSV, all kinds of source docs. Sometimes it works, sometimes not.

Any ideas? Running latest v. of TBX.
Image 5-15-24 at 07.20

When you write that you’ve tried “Numbers, Excel, CSV, TVS” do you mean you dragged each of those files into Tinderbox? It usually works most consistently to select a range with headers in a Numbers or Excel file, copy, then paste that range into Tinderbox. You can both paste ranges copied from CSV or TSV (sic) or the file itself.

Maybe if you could zip up a test file that’s not working for you and attach it to a message here, others can test with your non-personalized data?

1 Like

Agree with the good points above. Apologies if you’ve seen already but factors around this functionality are summarised at: Spreadsheet Import: CSV and Tab-Delimited Text.

Although reflecting some issues now lessened by more recent improvements to data import, this may also prove useful.

Checks and as per first link above:

There is no menu option for initiating tabular data import. For tabular data two formats are supported, tab-delimited (TSV) or comma-separated (CSV):

  • Tab-delimited: supported for file drag drop and copy/paste of table data. For files use ‘.txt’ or ‘.tsv’ file extensions.
  • CSV: supported for file drag drop (CSV copy/paste is not supported). For files use the ‘.csv’ file extension.

Notre the differences between TSV and CSV and that CSV copy/paste is not currently supported. THat said if copying from a spearsheet I think TSV (i.e. Tab-delimited) is the default form in which the data is placed on the clipboard. At least—as, hidden from us, the clipboard often holds several versions of the copied data—I think TSV is the basic plain text version that gets stored.

Also note the caveats at the bottom of the above article, about CSV-related issues.

1 Like

(testing) When pasting/dropping do do onto the background of the view. In a map it is possible to drop data such that you unintentionally drop it onto the $Name or $Subtitle area causing Tinderbox to, quite reasonably, assume you are editing one of those fields.

Other things that can interfere with spreadsheet import:

• empty cells. Tinderbox checks that the imported data is rectangular. Empty cells at the end of a row might lead Tinderbox to conclude that this isn’t a spreadsheet at all.

• column headers that cannot be attribute names. Attributes start with a letter, and attribute names cannot contain spaces or punctuation.

1 Like

Re attribute names, see Attribute Naming.

If empty cells—especially if the last cell in a row—are a possible problem, an old trick is to add a new right-most column and make sure every row has a dummy value. The latter value doesn’t matter - you won’t use the data and can delete it (and its attribute) once the import has occurred.

Thanks all for the helpful suggestions. So far I’ve only tried copy/paste, from various spreadsheet formats, and tried doing the same in both map and outline views, with fully populated cell ranges, etc. I will have to do a more orderly investigation. I’ll perhaps post a sanitized file a bit later if need be… graçias

One useful approach is just to paste the first handful of rows. Does that work as you expect?

If it doesn’t, you have a nice, small, easily-sanitized example.

If it does work, try the first half. Does that work as you expect? If it does, the problem lies in the second half! If not, there’s a problem in the first half. Either way, you’ve isolated the issue.

Repeat!

1 Like

Good idea. I was noticing that pasting subsets of data from a larger table is more likely to be successful. Experiments are ongoing–will report back.

2 Likes

Divide and conquer is VERY effective for finding the problem spot.

Suppose you copy 1000 rows, and something is amiss. But you copy the first two rows, and that’s OK.

  1. Try 500 rows? Are things ok? If they are, the problem is in the second 500.
  2. If not, try 250 rows. Are things ok? If they are, there’s a problem in row 251-500.

You can narrow things down very quickly to a handful of rows.

1 Like

As a long time data-wrangler, things that ought to ‘just’ work, often don’t. I thoroughly commend the sampling approach. Ideally, these unexpected results ought not to happen, but they do. Divide and conquer! Also, if you are lucky enough to find an unpredicted cause of a problem, do report it. With a repeatable trigger, the chance of a (future) cure increase massively. :slight_smile: