Shiny app works locally, but reports "No data available in table"



I have a Shiny app (my first) that was previously working fine on Today I updated the system software on my Mac to High Sierra, and updated from R 3.3.3 to 3.5.1. I also updated all R packages. My app still runs fine locally in RStudio (and the app code is unchanged). But now on the two datatables report "No data available in table", and the boxplot and faceted histogram are blank. Oddly, the time series in the app using dygraphs, which is built inside the app from the same data, still works.

I'm stumped. Does anyone have any idea what might be causing this and what to do about it? I'm happy to try to provide any additional information that might help troubleshoot. This is my first Shiny app, and I'm still a newbie.



Welcome to the Community and to using Shiny. I'm sorry you're having issues.

Here are some places to look first:

If that doesn't help you resolve the issue, please follow up with:

  • Any error or warning messages, and where you receive them.
  • Cite your application logs.
  • Cite output of "rsconnect::appDependencies()"
  • Provide your shiny app's application URL/id.


Thanks for answering! I had already looked at Troubleshooting and the support topics last night before I wrote here, and I didn't see anything that matched the problem I'm having.

There aren't any warning messages. The app URL is:

The log doesn't show any warnings except for the "incomplete final line" in one of the .Rmd files (which I'll fix). But here they are:

2018-08-13T15:06:32.145283+00:00 shinyapps[399008]: LANG: en_US.UTF-8 
2018-08-13T15:06:32.145285+00:00 shinyapps[399008]: R version: 3.5.1 
2018-08-13T15:06:32.145288+00:00 shinyapps[399008]: httpuv version: 1.4.5
2018-08-13T15:06:32.145287+00:00 shinyapps[399008]: shiny version: 1.1.0 
2018-08-13T15:06:32.145312+00:00 shinyapps[399008]: jsonlite version: 1.5 
2018-08-13T15:06:32.145320+00:00 shinyapps[399008]: RJSONIO version: NA 
2018-08-13T15:06:32.145296+00:00 shinyapps[399008]: rmarkdown version: 1.10 
2018-08-13T15:06:32.355600+00:00 shinyapps[399008]: Using jsonlite for JSON processing 
2018-08-13T15:06:32.361893+00:00 shinyapps[399008]: 
2018-08-13T15:06:32.145302+00:00 shinyapps[399008]: knitr version: 1.20 
2018-08-13T15:06:33.337783+00:00 shinyapps[399008]: ── Attaching packages ─────────────────────────────────────── tidyverse 1.2.1 ── 2018-08-13T15:06:33.343174+00:00 shinyapps[399008]: βœ” ggplot2 3.0.0 βœ” purrr 0.2.5 
2018-08-13T15:06:33.343177+00:00 shinyapps[399008]: βœ” tibble 1.4.2 βœ” dplyr 0.7.6 
2018-08-13T15:06:33.343179+00:00 shinyapps[399008]: βœ” tidyr 0.8.1 βœ” stringr 1.3.1 
2018-08-13T15:06:33.343180+00:00 shinyapps[399008]: βœ” readr 1.1.1 βœ” forcats 0.3.0 
2018-08-13T15:06:33.452584+00:00 shinyapps[399008]: ── Conflicts ────────────────────────────────────────── tidyverse_conflicts() ── 
2018-08-13T15:06:33.452587+00:00 shinyapps[399008]: βœ– dplyr::filter() masks stats::filter() 
2018-08-13T15:06:33.452588+00:00 shinyapps[399008]: βœ– dplyr::lag() masks stats::lag() 
2018-08-13T15:06:33.460776+00:00 shinyapps[399008]: 
2018-08-13T15:06:33.460779+00:00 shinyapps[399008]: Attaching package: β€˜lubridate’ 
2018-08-13T15:06:33.460781+00:00 shinyapps[399008]: 
2018-08-13T15:06:33.461572+00:00 shinyapps[399008]: The following object is masked from β€˜package:base’: 2018-08-13T15:06:33.461574+00:00 shinyapps[399008]: 
2018-08-13T15:06:33.461575+00:00 shinyapps[399008]: date 
2018-08-13T15:06:33.461576+00:00 shinyapps[399008]: 
2018-08-13T15:06:33.487957+00:00 shinyapps[399008]: 
2018-08-13T15:06:33.487960+00:00 shinyapps[399008]: Attaching package: β€˜DT’ 
2018-08-13T15:06:33.488444+00:00 shinyapps[399008]: The following objects are masked from β€˜package:shiny’: 
2018-08-13T15:06:33.487961+00:00 shinyapps[399008]: 
2018-08-13T15:06:33.488446+00:00 shinyapps[399008]: 
2018-08-13T15:06:33.488447+00:00 shinyapps[399008]: dataTableOutput, renderDataTable 
2018-08-13T15:06:33.488448+00:00 shinyapps[399008]: 
2018-08-13T15:06:33.532712+00:00 shinyapps[399008]: Loading required package: zoo 
2018-08-13T15:06:33.538458+00:00 shinyapps[399008]: 
2018-08-13T15:06:33.538460+00:00 shinyapps[399008]: Attaching package: β€˜zoo’ 
2018-08-13T15:06:33.538461+00:00 shinyapps[399008]: 
2018-08-13T15:06:33.538854+00:00 shinyapps[399008]: The following objects are masked from β€˜package:base’: 2018-08-13T15:06:33.538856+00:00 shinyapps[399008]: 
2018-08-13T15:06:33.538857+00:00 shinyapps[399008]: as.Date, as.Date.numeric 
2018-08-13T15:06:33.538858+00:00 shinyapps[399008]: 
2018-08-13T15:06:33.558896+00:00 shinyapps[399008]: 
2018-08-13T15:06:33.558899+00:00 shinyapps[399008]: Attaching package: β€˜xts’ 
2018-08-13T15:06:33.558900+00:00 shinyapps[399008]: 
2018-08-13T15:06:33.559313+00:00 shinyapps[399008]: The following objects are masked from β€˜package:dplyr’: 2018-08-13T15:06:33.559315+00:00 shinyapps[399008]: 
2018-08-13T15:06:33.559316+00:00 shinyapps[399008]: first, last 
2018-08-13T15:06:33.559317+00:00 shinyapps[399008]: 
2018-08-13T15:06:33.656141+00:00 shinyapps[399008]: Warning in readLines(con) : 
2018-08-13T15:06:33.656144+00:00 shinyapps[399008]: incomplete final line found on 'burgtheater-boxplot.Rmd' 
2018-08-13T15:06:33.674648+00:00 shinyapps[399008]: 
2018-08-13T15:06:33.674651+00:00 shinyapps[399008]: Listening on

And here is the output from "rsconnect::appDependencies()":

package version source
1 BH 1.66.0-1 CRAN
2 DBI 1.0.0 CRAN
3 DT 0.4 CRAN
4 MASS 7.3-50 CRAN
5 Matrix 1.2-14 CRAN
6 R6 2.2.2 CRAN
7 RColorBrewer 1.1-2 CRAN
8 Rcpp 0.12.18 CRAN
9 assertthat 0.2.0 CRAN
10 backports 1.1.2 CRAN
11 base64enc 0.1-3 CRAN
12 bindr 0.1.1 CRAN
13 bindrcpp 0.2.2 CRAN
14 broom 0.5.0 CRAN
15 callr 2.0.4 CRAN
16 cellranger 1.1.0 CRAN
17 cli 1.0.0 CRAN
18 clipr 0.4.1 CRAN
19 colorspace 1.3-2 CRAN
20 crayon 1.3.4 CRAN
21 crosstalk 1.0.0 CRAN
22 curl 3.2 CRAN
23 dbplyr 1.2.2 CRAN
24 digest 0.6.15 CRAN
25 dplyr 0.7.6 CRAN
26 dygraphs CRAN
27 evaluate 0.11 CRAN
28 fansi 0.2.3 CRAN
29 forcats 0.3.0 CRAN
30 ggplot2 3.0.0 CRAN
31 glue 1.3.0 CRAN
32 gtable 0.2.0 CRAN
33 haven 1.1.2 CRAN
34 highr 0.7 CRAN
35 hms 0.4.2 CRAN
36 htmltools 0.3.6 CRAN
37 htmlwidgets 1.2 CRAN
38 httpuv 1.4.5 CRAN
39 httr 1.3.1 CRAN
40 jsonlite 1.5 CRAN
41 knitr 1.20 CRAN
42 labeling 0.3 CRAN
43 later 0.7.3 CRAN
44 lattice 0.20-35 CRAN
45 lazyeval 0.2.1 CRAN
46 lubridate 1.7.4 CRAN
47 magrittr 1.5 CRAN
48 markdown 0.8 CRAN
49 mgcv 1.8-24 CRAN
50 mime 0.5 CRAN
51 modelr 0.1.2 CRAN
52 munsell 0.5.0 CRAN
53 nlme 3.1-137 CRAN
54 openssl 1.0.2 CRAN
55 packrat 0.4.9-3 CRAN
56 pillar 1.3.0 CRAN
57 pkgconfig 2.0.1 CRAN
58 plogr 0.2.0 CRAN
59 plyr 1.8.4 CRAN
60 praise 1.0.0 CRAN
61 processx 3.1.0 CRAN
62 promises 1.0.1 CRAN
63 purrr 0.2.5 CRAN
64 readr 1.1.1 CRAN
65 readxl 1.1.0 CRAN
66 rematch 1.0.1 CRAN
67 reprex 0.2.0 CRAN
68 reshape2 1.4.3 CRAN
69 rlang 0.2.1 CRAN
70 rmarkdown 1.10 CRAN
71 rprojroot 1.3-2 CRAN
72 rstudioapi 0.7 CRAN
73 rvest 0.3.2 CRAN
74 scales 1.0.0 CRAN
75 selectr 0.4-1 CRAN
76 shiny 1.1.0 CRAN
77 shinythemes 1.1.1 CRAN
78 sourcetools 0.1.7 CRAN
79 stringi 1.2.4 CRAN
80 stringr 1.3.1 CRAN
81 testthat 2.0.0 CRAN
82 tibble 1.4.2 CRAN
83 tidyr 0.8.1 CRAN
84 tidyselect 0.2.4 CRAN
85 tidyverse 1.2.1 CRAN
86 tinytex 0.6 CRAN
87 utf8 1.1.4 CRAN
88 viridisLite 0.3.0 CRAN
89 whisker 0.3-2 CRAN
90 withr 2.1.2 CRAN
91 xfun 0.3 CRAN
92 xml2 1.2.0 CRAN
93 xtable 1.8-2 CRAN
94 xts 0.11-0 CRAN
95 yaml 2.2.0 CRAN
96 zoo 1.8-3 CRAN

The ones I'm actually loading in the app:



So, something that I noticed is that if I fill in the end date, that data appears.

I wonder if in your upgrading you are hitting a change in behavior in the date range input such that the end date is not being pre-filled?


Interesting. I hadn't noticed that the end date was missing in the online version (it's filled in properly when I run it locally). I'll take a look at this now.

Here's the relevant code in the app:

         # Do not show with dygraph tab
         condition = "input.tabselected != 6",
         dateRangeInput(inputId = "dates",
                        label = "Dates",
                        start = "1789-04-14",
                        end = "1791-03-07",
                        min = "1789-04-14",
                        max = "1791-03-07"
         ), # End dateRangeInput
         HTML("<p class='small'>The season 1789/90 ended on 1790-02-11
               <br>The season 1790/91 began on 1790-04-13<br><br></p>")

So the end date should be showing. I wonder why it isn't....


Another odd thing is that the box for the end date won't accept "1791-03-07" (which it should) but it will accept "1791-03-06".

The final date in the dataset is definitely 1791-03-07. The original dataset is here:

And I just double checked that this is correct in the file operas.Rdata that the app uses. It is.


Ah, I see that this also happens when I open the app locally in an external browser, something I hadn't checked.


It looks like this is due to the dateRangeInput having an off-by-one error for the max value, on Chrome. It works fine on Safari and Firefox for me.

The problem seems to occur with dates that are far in the past -- it didn't happen for more recent dates when I tested.

I've filed an issue here:


The problem also happens in Opera.

Any suggestions for a work around that would make it work in all browsers?


Although I haven't tested it thoroughly, it seems to work in all browsers (I don't have a Windows computer, so I can't test Edge) if I change to max = "1791-03-08". I'm going to push that revision to for now.


The simplest workaround would be to just increase the max by one day. We'll try to look into this and fix it soon.


Thanks! You guys have been great!


P. S. Although I see now that the dates on the dygraph time series now show one day earlier than they should (for example, 1789-04-14 in the data displays as Apr 13. I'm going to see if I can find a workaround for that.


My temp fix for the dygraphs date bug:

 # Make xts time series for dygraphs time-series plot
   # Includes "+1" workaround for date bug
   operas_xts <- reactive({
     receipts <- xts(operas_selected()$Receipts,
                     as_date(operas_selected()$Date) + 1)
     colnames(receipts) <- "kr"
     new <- as_date("1790-02-13")
     receipts <- merge.xts(receipts, new)
   }) # End reactive operas_xts

Tne +1 seems to work, and I've also had to add 1 to the correct date "1790-02-12" to get the vertical line to display properly.

You should know that this fix makes the dates display incorrectly (that is, one day too late) in the RStudio browser. This discrepancy between the behavior of the RStudio browser and external browsers in displaying these dates goes back a ways. I had asked a question on StackOverflow about that a year ago:

At that time, the dates showed correctly in external browsers but were one day early in the RStudio browser. Something has evidently been changed since then, but it's still not working quite right.

If the issue gets fixed, and someone happens to think of it, maybe leave a follow-up here so that I can take out the temporary fix.

But many thanks again. I need to check a bit more to make sure that the "fix" doesn't have unintended consequences, but at least I probably now have a version I can show colleagues for feedback.


I hit a similar issue recently using the Javascript Date constructor to parse dates in yyyy-mm-dd format. Apparently date string parsing in Javascript is just really wacky, with gotchas and browser inconsistencies all over. From what I understand, some browsers parse yyyy-mm-dd strings as ISO 8601 dates in UTC, not the local timezone. When that gets converted back to the local timezone, it may be a different day.

From the MDN docs

Note: parsing of date strings with the Date constructor (and Date.parse , they are equivalent) is strongly discouraged due to browser differences and inconsistencies. Support for RFC 2822 format strings is by convention only. Support for ISO 8601 formats differs in that date-only strings (e.g. "1970-01-01") are treated as UTC, not local.

The dygraphs blog also has a great write up with advice on date formats to use.

I think somewhere in the dateRangeInput (and also dateInput), date strings get parsed the same way. These formats seem to work around the issue in both the RStudio Viewer and Chrome. Should work on other browsers too, but I haven't tested to be 100% sure.


ui <- fluidPage(
  # doesn't work
                 label = "Dates",
                 start = "1789-04-14",
                 end = "1791-03-07",
                 min = "1789-04-14",
                 max = "1791-03-07"
  # slashes instead of dashes, works
                 label = "Dates",
                 start = "1789-04-14",
                 end = "1791-03-07",
                 min = "1789-04-14",
                 max = "1791/03/07"
  # add a time component, works (ISO 8601 format using local time, not UTC)
                 label = "Dates",
                 start = "1789-04-14",
                 end = "1791-03-07",
                 min = "1789-04-14",
                 max = "1791-03-07T00:00:00"
  # same issue and workaround with the dateInput
  dateInput("d", "date", value = "1789-03-09", max = "1789-03-09"),
  dateInput("d", "date", value = "1789-03-09", max = "1789/03/09")

server <- function(input, output) {}

shinyApp(ui, server)


Thanks so much for this, and sorry for not responding right away. I didn't get around to checking until just now, but as I should have expected, my hack to make the dates display correctly in the time series in Chrome and Opera makes them all display one day too high in Firefox and Safari.

I'll experiment with the options you describe and report back here if I find something that works in my app on all browsers.


OK. Using max = "1791/03/07" seems to take care of the problem in dateRangeInput(). But nothing I have tried so far has solved the problem in the dygraphs output. I've tried changing all dates to the "/" format, and all dates to "/" plus "T00:00:00", but there is still a one-day discrepancy in the dygraphs output between Firefox, Safari, and the R Studio browser on the one hand, and Chrome and Opera on the other. (I'm not able to test Edge.)

I'm no expert, but as I understand it, dygraphs in R will only accept an xts series, which means that the date strings are being converted to dates at the stage in the code where I construct the xts series (which won't accept them as strings), and then these dates are still interpreted incorrectly downstream in some browsers.

Any ideas? Is there a way to check in code in the Shiny for what browser is being used?