getTicks_Impl error while running getTicks

[ChloeTian]

While running getTicks, sometimes it throws error : getTicks_Impl(con, security, eventType, startUTC, endUTC, setCondCodes = returnAs %in% : std::bad_alloc), but sometimes it generates results without any errors.

Please find codes attached: library(Rblpapi) con <- blpConnect() start <- '2020-01-3008:00:00' end <- '2020-01-3020:55:55' tickData <- getTicks('ESH0 Index', eventType = c("BID","ASK"), startTime = as.POSIXct(start,tz='GMT') - 60 ,endTime = as.POSIXct(end,tz='GMT') - 60, verbose = FALSE, returnAs = getOption("blpType","data.frame"), tz = Sys.getenv("TZ", unset = "GMT"),con = defaultConnection())

Does anyone experience the same issue?

Thanks

[eddelbuettel]

Please take a look at e.g. this write-up at StackOverflow on how to create a minimally complete verifiable example. At present, we cannot help you with your issue.

As a simple sanity check at your end, try what it in the example part of help(getTicks):

  res <- getTicks("ES1 Index")
  str(res)
  head(res, 20)

[ChloeTian]

Please take a look at e.g. this write-up at StackOverflow on how to create a minimally complete verifiable example. At present, we cannot help you with your issue.

As a simple sanity check at your end, try what it in the example part of help(getTicks):

  res <- getTicks("ES1 Index")
  str(res)
  head(res, 20)

Sorry about the mistake I made when I raised this topic of issue. I have updated my descriptions of the questions. Thank you for your suggestions.

[eddelbuettel]

start <- '2020-01-3008:00:00' looks bad. What happens when you try an ISO 8601 date such as 2020-01-30 08:00:00. The space may matter.

Example:

 R> anytime::anytime("2020-01-3008:00:00") 
 [1] "2020-01-30 CST"  
 R>  

The start time is skipped, so start and end become the same.

[eddelbuettel]

Could you please confirm that things work fine when you correctly enter start and end time?

[ChloeTian]

Could you please confirm that things work fine when you correctly enter start and end time?

Unfortunately, I guess it still throws the error sometimes.

[eddelbuettel]

"Sometimes" is not something we can help with very easily.

If you can, please provide a simple and reproducible example -- and then feel free to reopen the issue with it, but I will now close it for lack of specifics.