Limit on events being imported?

[Stanley]

George:
No need to supply the .csv files. I do not have a column for STATUS and visually checked with NOTEPAD++. I checked the .ics files with NOTEPAD++ and there is a field called STATUS: CONFIRMED in there just as your validator shows.

[George]

Indeed the “STATUS: CONFIRMED” field exists in the ICS files—this is what is being reported as an “error”.

But if this doesn’t come from your CSV files, then I wonder where it’s coming from? Do you happen to know? I cannot generate CSV files from my local site or anything with a “STATUS: CONFIRMED”-type field…

I apologize for harping on this “STATUS: CONFIRMED” field, but it’s the only thing standing out as problematic here.

Stay tuned — I am going to modify the file and recommend something that might be a helpful experiment.

— George

[George]

Stanley,

Are you certain there are NO duplicates at all in this file? If so, what is the means by which you are confirming there are absolutely no duplicate events?

— George

[Stanley]

George:
You have brought up two questions, the first was answered in my reply to you on the 15th where I gave you the website for the product that I am using to convert from .csv to .ics. Here it is again: https://csv-to-ics.com/.

UPDATE EDIT: It didn’t display again using the link button so manually entered it, again.

The second question about duplicates is the first time you are bringing that up in this thread. I have never said that there are not duplicates because I need you to define what is a duplicate. Is it the same event on the same day in the same year (IOW, two of the same records)? Is it an event with the same title from a previous year falling on the same day but in a different year? Is it an event with the same title and the same day from a prior year, but having the same title and falling on the same day in the next year? Let me know, but again, reviewing the .ics file I sent you several days ago and which you tested will allow you or the developers to see if there are duplicates since there were four years in the one file.

• This reply was modified 9 years, 2 months ago by Stanley. Reason: url link did not work again for this url

[George]

Hi Stanley,

Thanks for your update here. I wanted to let you know I have reported this thread to a developer on our team who will be helping me take a closer look at your file and these issues.

As we head into the weekend, I apologize for the pace of this investigation. As noted above, this is an odd set of issues that we can’t recreate with other files and so it’s taking some time to investigate.

Please respond to each of the three questions that follow:

---

Question #1

Indeed the “STATUS: CONFIRMED” field exists in the ICS files—this is what is being reported as an “error”.

You mentioned above that there is no “status” column in your original CSV file. And so the pesky “STATUS: CONFIRMED” field in your ICS file doesn’t come from your CSV files.

• Where is it coming from, then? Do you happen to know? I cannot generate CSV files from my local site or anything with a “STATUS: CONFIRMED”-type field. I apologize for harping on this “STATUS: CONFIRMED” field, but it’s the only thing standing out as problematic here.

---

Question #2

In regards to your questions about what I mean by duplicates, I am talking about events with the same title and same date—”same date” meaning same time, day, and year. So if there are multiple instances of “Event A” on May 1, 2017, then that would be an example of duplicates. But if there’s an instance of “Event A” on May 1, 2017, then another instance of it on May 1, 2018, this would not be a duplicate.

• Are there any such duplicates in your file? Yes, I am checking manually myself, by given the size of the file that is taking some time and so I am just curious if you have any knowledge of this yourself.

---

Question #3

• Can you please share the original CSV file with us? Upload it to Dropbox, Google Drive, CloudUp, etc., and we’ll download it from there.

---

Thank you for your continued patience and persistence,
George

[Stanley]

George:
I’ll repeat again the answer(s) to your questions:
QUESTION #1: On two previous occasions (02/15 & 02/16/17) I gave you the website name of https://www.csv-to-ics.com/ as the product that does the conversion of the csv to ics file.

QUESTION #2: There are NO duplicates in the csv file based on your definition of “duplicate”.

QUESTION #3: The original csv file is in Dropbox. https://www.dropbox.com/home?preview=BC-RACES+Nets+2017-2021-1.csv

[George]

Hey Stanley,

Thanks for this. If it seems like I’ve asked the same questions a number of times, I have not, and am sorry for the pace of this investigation.

As an example, for “Question 1”, I am not asking what tool you used to convert the CSV to ICS. You indeed already shared this.

The main question I am asking is where is the STATUS: tag coming from in the ICS file? There’s no “status” column in your original CSV file. So does this mean that the csv-to-ics tool you’re using is just adding the Status column itself? If so, can you disable this so that no “STATUS” column is added, then try importing that version of the ICS file that doesn’t have the STATUS: field?

I appreciate your clarification of the other two questions and am genuinely appreciative of your patience here. This is an odd problem that we’re actively trying to figure out and I hope to have some more useful information about the nature of this problem for you soon.

Thank you,
George

[Stanley]

Yes, George. The converter that is being used was putting in the STATUS:CONFIRMED field according to the iCalendar spec RFC 5545. However, the converter developer removed the STATUS:CONFIRMED field since it is by default CONFIRMED if it is valid. I reran the same .csv file and then attempted to import the NEW file w/o the STATUS field (I confirmed it was removed using NOTEPAD++) and the records STILL STOP AT 45 in the preview screen of the import. The developer is going to look at the file again, but it seems OK from his standpoint. Do you have some type of limit anywhere in the import program that maybe a developer forgot to remove when testing? Believe me, I HAVE BEEN THERE in managing computer programmers. Please remember, the file works when input into OUTLOOK calendar.

[Stanley]

George:
The software developer just got back to me and finds nothing wrong with the file output. He also imported all 113 events into OUTLOOK and his own calendar product. IT IS OBVIOUS TO ME THAT THE PROBLEM LIES IN AGGREGATOR’s IMPORT FUNCTION.. It is about time that this problem be raised to a higher level in software development as it has gone on entirely too long. Please raise this matter to middle management immediately.
Thanks.

[George]

Sure thing Stanley, sit tight while I escalate this issue to our development team and we take a closer look at why such a small number of events are showing up.

Stay tuned.
George

[Stanley]

George:
What is happening with this matter? I see a “pending fix” is in the works, but any ETA?

[George]

I’m sorry Stanley — one of our developers is working on these issues, but a proper update may not arrive until Monday of next week or later. I am sorry about that but here’s the reason why it’s taking a while:

• You are right that your files are fine, we’ve confirmed.
• With other files that are also fine, we’re not recreating this problem.
• And so…it’s a weird puzzle about why your valid files would have issues that other valid files are not having.

I totally understand how frustrating the pace of this can be and appreciate your patience while we work on this. I can confirm that this isn’t “abandoned” or anything, though, and am sorry if my lack of updates gave that impression—there just wasn’t much to say other than “we’re still working on it”, but I will try to confirm that now more regularly so it doesn’t appear abandoned.

Please let me know if there are any other issues or questions I can try to help with while we continue to work on this!

— George

[Stanley]

OK George. Thanks for the update.

[George]

Hi Stanley,

I wanted to let you know that our developers have been able to identify some behaviors in our code that might be causing this. I am really, really sorry for the pace of this investigation — as noted above, it’s a weird one and we’ve had to rope in some of our senior developers to look at this (whose schedules are quite packed, which is another factor adding to the amount of time this is taking).

Stay tuned — this issue is not forgotten!
George

[Stanley]

Thank you. Standing by….

[Author]

Posts