У меня есть куча sql-запросов, которые работали нормально, но теперь по какой-то причине больше не работают. Данные не изменились. Код не изменился.
Я все время получаю это сообщение об ошибке:
Ошибка в rsqlite_send_query (conn @ ptr, statement): повторяющееся имя столбца: Ret
Эти ошибки обычно происходят с левыми соединениями. Найдите ниже пример:
g.cper<-sqldf("select a.*, b.NAV_EUR, b.AUM_EUR
from g2_c as a
left join
nav_master as b
on a.fund_id=b.fund_id and a.period = b.period")
Ни в одной из рассматриваемых таблиц нет переменной с именем "Ret".
Я недавно обновил все свои пакеты.
Это устаревший код. Я стараюсь использовать dplyr :: left_join, когда это возможно. Но left_join никогда не будет делать то, что может достичь левое соединение в SQL (неравенства как ограничения и т. Д.).
Я загружаю следующие пакеты:
пакеты ‹- c (" ISLR "," gam "," biglm "," dplyr "," gtools "," tidyr "," randomForest "," splines "," tree "," pROC "," lfe "," lubridate "," звездочет "," scale "," ggplot2 "," scale "," data.table "," zoo "," PerformanceAnalytics "," stats "," proto "," timeSeries "," timeDate "," gsubfn "," fBasics "," DBI "," RSQLite "," sqldf "," RODBC "," tcltk "," reshape "," xts "," data.table "," parallel "," lfe "," readr, purrr, tibble, hms, stringr, lubridate, forcats)
Это моя sessioninfo ():
sessionInfo () R версии 3.3.3 (2017-03-06) Платформа: x86_64-redhat-linux-gnu (64-разрядная) Работает под: Red Hat Enterprise Linux Server 7.3 (Maipo)
локаль: 1 LC_CTYPE = en_US.UTF -8 LC_NUMERIC = C
LC_TIME = en_US.UTF-8 [4] LC_COLLATE = en_US.UTF-8
LC_MONETARY = en_US.UTF-8 LC_MESSAGES = en_US.UTF-8 [7] LC_PAPER = en_US.UTF -8 LC_NAME = C LC_ADDRESS = C
[10] LC_TELEPHONE = C LC_MEASUREMENT = en_US.UTF-8 LC_IDENTIFICATION = Cприкрепленные базовые пакеты: 1 параллельные сплайны tcltk статистика
графика grDevices utils datasets база методовдругие прикрепленные пакеты: 1 forcats_0.2.0
stringr_1.2.0 hms_0.3 [4] tibble_1.2 purrr_0.2.2
readr_1.0.0 [7] reshape_0.8.6
RODBC_1.3-14 sqldf_0.4-10 [10] RSQLite_1.1- 2 fBasics_3011.87
gsubfn_0.6-6 [13] timeSeries_3022.101.2
timeDate_3012.100 proto_1.0.0 [16] PerformanceAnalytics_1.4.3541 xts_0.9-7 zoo_1.7-14 [19] data.table_1. 10.4 ggplot2_2.2.1
scale_0.4.1 [22] stargazer_5.2
lubridate_1.6.0 lfe_2.5-1998 [25] Matrix_1.2-8 pROC_1.9.1
tree_1.0-37 [28] randomForest_4 .6-12
tidyr_0.6.1 gtools_3.5.0 [31] dplyr_0.5.0 biglm_0.9-1 DBI_0.5-1 [34] gam_1.14 foreach_1.4.3
ISLR_1.0загружается через пространство имен (и не прикрепляется): 1 reshape2_1.4.2
lattice_0.20-34 colorspace_1.3-2 chron_2.3-50 plyr_1.8.4
munsell_0.4.3 [7] gtable_0.2.0 codetools_0.2-15 memoise_1.0.0 labeling_0.3 Rcpp_0.12.9 xtable_1.8-2 [13] digest_0.6.12 stringi_1.1.2 grid_3.3.3 tools_3.3.3 sandwich_2.3-4
magrittr_1.5 [19] lazyeval_0.2.0 Formula_1.2-1 assertthat_0.1 iterators_1. 0,8 R6_2.2.0
Не уверен, связано ли это с этим вопросом Имейте в виду, что я использую RSQLite_1.1-2 (ранее, чем 2.0)
Я, честно говоря, не знаю, что происходит, и ничего в сети не нашел ...
ОБНОВЛЕНИЕ I: я обновился до sqldf_0.4-11 и RSQLite_2.0 .... Проблема все еще возникает. Я также пробовал загрузить sqldf (и зависимости) .... Код все еще не работает
ОБНОВЛЕНИЕ II. Прежде всего, я хотел бы поблагодарить Г. Гротендику за его помощь в этом вопросе и за его вклад в R все эти годы.
По этой конкретной проблеме я попытался запустить тестовый запрос с помощью mtcars. Это код:
b<- sqldf("select a.*, b.mpg as test
from mtcars as a
left join
mtcars as b
on a.mpg=b.mpg")
Этот запрос сработал !!!. Затем я запускаю код, который не работал даже после обновления до sqldf 0.4.11 и RSQLite 2.0 (см. Обновление I). К моему удивлению, теперь это работает !!! .... Я не знаю, что случилось, но все мои запросы sqldf теперь работают. К вашему сведению ... Я работаю в AWS ............ Иногда происходят необъяснимые странные вещи ...
ОБНОВЛЕНИЕ III. Проблема вернулась. Поэтому я снова запускаю тестовый код в обновлении II. Это работает. И после запуска этого тестового кода все мои соединения с sqldf снова работают ... ПЕРЕЙДИТЕ НА РИСУНОК
RSQLite
до 2.1.1 - person jsta   schedule 02.09.2018