This might a version or return of a problem mentioned on community some years ago and marked as solved.
I am getting a problem where the (huge!) integers used for objectIds are not read properly if I upload them as a simple .csv file in the Portal.
For example, a file that starts as:
name_1,objectId,coord_ra,coord_dec
1RXS J160929.1-210524B,762266397647596966,242.37620126341753,-21.08320526467467
2MASS J00062250+1300451,798914357151925539,1.5939615213680893,13.012076073925172
2MASS J00065552+0236376,787328184654777539,1.7305295846161663,2.6089368836270914
then used to match to the ForcedSource table in the Portal view by objectId.
Returns bogus matches, apparently because the objectId is not read correctly. I return the user columns by including ut.* in the ADL query. Example from above:
2MASS J00062250+1300451,798914357151925539
is listed as 7.989143571519255E17 in the user table columns (i.e., it’s been converted to float and lost precision) and therefore matches to the incorrect objectId 798914357151925504
Of course, all this fails silently because there are enough objectIds in the ForcedSource database that the new incorrect ones often match a real objectId.
Admittedly, I went to no effort to specify the format to be used, but it does seem like this is a bug and flaw in the user interface.
[Note that I can accomplish this task with joins, the notebook mode, etc.]