If you can follow the way I described in Zero to Emacs and Org-roam guide, then you can download and place an executable file. Does a copy of the emacsql-sqlite.exe I compiled and use work for you?
Thanks! I will certainly try that, when I migrate my notes to v2, and I donāt see a reason why the .exe you build should not work for me.
Mainly I just wanted to raise awareness of users of org-roam who cannot compile source code simply because they need to run org-roam on systems they have limited control over at work or school.
Iām also not saying that you necessarily should support this group ā I understand OSS developer time is limited, and you may be trying to minimize the complexity.
Yeah, makes sense.
For these reasons, v2 might be the end of org-roam for me. Adding an executable will make it inaccessible in my windows-centric, security-focused environment.
Possibly. And thatās unfortunate.
But not so quick. How did you get sqlite3.exe for V1 to work in your environment? Did you already have it installed by the system admin?
If this could be done for V1, it might be possible to meet V2ās additional software requirement.
Yes, sqlite3.exe was already available/approved on my Win10 system. Similar to agisgaās post, I would need to have emacsql-sqlite.exe approved by IT security and this is much less likely with an entity that they are not familiar with. I am very grateful for all of the your posts and efforts on this project! I donāt normally post, but have become very attached to Org-roam.
Thank you, @Toe.
You might like to consider this below.
Jethro mentioned this in a recent GitHub issue:
You can use emacsql-sqlite3 if you want (by changing the code locally), thereās no hard dependency on the foreign keys for now. Iāve tried the pragma directive and it doesnāt work.
I donāt think Iāll have time to test this workaround untilā¦ sometime this weekend. But it might give you a way (emacsql-sqlite3 is the package used by V1 with no need for the additional executable file).
@jethro Do you think you will keep emacsql-sqlite3 as a long-term option, or just a temporary window of opportunity that users can exploit?
Thanks for the GitHub link.
This gets me further along in the process, but I cannot get it to work completely.
Can anyone who has had luck getting emacsql-sqlite3 to work with V2 provide any tips?
Iām also very interested to see a solution 
I didnāt have time to try myself yet. I decided against using the precompiled executable provided by nobiot, because colleagues were getting caught and getting some trouble recently for using software that is not on our approved software list (which the official sqlite binaries are). For now I stopped using org-roam at work ā I now mainly rely on deft to browse my notes and insert links (org-store-link / org-insert-link etc.), rely on git-grep to find backlinks, helm-bibtex for references, etc., wrapped in a bunch of custom functions. This is sufficient for my purposes but obviously not as convenient or powerful as org-roam v2 
In case this helps someone, Iām able to use the following workaround in a restricted windows environment with no admin rights:
The software MobaXterm has an official portable version, so does not need to be āinstalledā, and also is free (also happens to be āapproved softwareā in my case). Built into MobaXterm is an (āexperimentalā) package manager called MobApt, that can be used to install Emacs 26.2 (including GUI) and GCC 7.4.0 (also some other tools). I.e., the installed emacs has to be started from within MobaXterm to be used, and has only access to the directory specified in MobaXtermās settings as the root directory. Org-roam v2 seems to work with no issues on that emacs instance (maybe a little slower than otherwise), although I havenāt tested this setup extensively yet.
1 Like
Anecdotally, Iāve very recently stumbled into the "Selecting deleted buffer" issue (and then fixed it by adapting the hack described here). A few things Iāll note of my experience:
- I didnāt actually manage to fix the issue properly. I had to hack in
sqlite3. I still do not understand why when I start up org-roam it does not create anorg-roam.dbin the directory. This concerns me since I donāt want to worry about conflicts and odd behavior everytime I updateorg-roam. - Itās not at all obvious what is the connection between seeing the message
apply: selecting deleted bufferand theemacsql-sqlitebinary not existing. It took me about a week of on-and-off sleuthing to figure this out (me not being very good at edebug yet).- This requirement for
gccto be present also severely complicates my.emacs.dconfiguration, now that I have to ensure a whole toolchain is present on windows machines, instead of justsqlite3.
- This requirement for
- While I acknowledge the reasoning in favor of using
emacsql-sqliteoveremacsql-sqlite3(future performance and code clarity via the use of foreign keys, as I understand it), I struggle as a user to relate with this perspective as I am confronted with my org-roam setup simply not working on my windows machine. Iām sure Iāll relate better now that my setup is working and my hierarchy of needs now includes speedy operations.
Overall my opinion is that the ergonomic hit of forcing emacsql-sqlite onto windows users is probably not worth the currently-unrealized gains of using emacsql-sqlite-specific features. I am not yet convinced that the benefits of using those features would outweigh the downsides of having to install gcc on every windows userās machine.
Happy to be proven wrong, of course.
Just an update: Although I know it is not officially recommended
(setq org-roam-database-connector 'sqlite3)
has been working with no known problems and I am now happily on V2!
@Toe Thank you; I have also been using sqlite3 option on my Windows machine for a while.
With version 2.2.0, it should be āofficially supportedā. See this change log entry:
This PR I proposed was intended to fix the long-niggling issue with sqlite3; it has been working OK on my end, too 
