javier, C, C++, or for that matter, any language capable of creating a Win32 DLL, Most EXPORTED functions are callable within RBase, excluding ones that require integers that are full 32 bit or 64 bit.
That was the purpose of DLCall. When the foreign DLL is introduced into the address space of the RBase session, the EXPORTED functions are just a functional as the native RBase functions. On Tuesday, July 14, 2020 at 6:53:59 PM UTC-4, javier.valencia wrote: > > *This post is neither an advertisement or endorsement of any product other > than R:Base nor an offer or request for work.* > > > > I have been working with an application developed by a colleague that > performs advance analysis that I want to incorporate into my own R:Base > application for a client which could potentially lead to other clients > looking for a similar solution. > > The application was written in C++ and accesses a MS Access database. Most > of the primary tables in that application are based on/copied from tables > in my own application so they have the same table structure > > My solution to date is to SConnect to the MS Access database, SAttach the > required tables and synchronize data in both databases, run the analysis > and then transfer results to the R:Base database. While this approach works > relatively well it is probably far from optimal particularly when we scale > up to a much larger data set; I would much rather use only the R:Base > database and use the existing C++ code to access data and stored results > directly and od away with MS Access database altogether. > > My questions are: what does it take to make the C++ code access data in > the R:Base database? Can I access it directly or do I need to go through > Oterro? > > The potential client has looked at the various options and his IT > department has ruled out using Oterro. > > The options at this point are : > > 1 - Make the C++ code work with the R:Base database without using Oterro – > Preferred > > 2 - Rewrite the C++ code in R:Base which would require a large amount of > effort since a lot of the constructs in C++ are not readily available in > R:Base and vice versa - Probably not practical > > 3 - Move the entire application to a different database that is accessible > directly from R:Base and from C++ code and use R:Base as a front end for > menus, forms and report – I understand others have done this but I have not > done it myself so I am not sure on what is involved and how well it works. > > 4. Pass on the project and retire once and for all…perhaps the best option? > > Having used it for over 35 years, I would prefer to stay within the R:Base > environment because I am most familiar with it. Before R:Base I spent 6 > years writing C code to access databases in the Unix environment, so, while > my C programming skills are dated, I can probably come up to speed fairly > quickly. Any information or insights you can offer will be greatly > appreciated. > > > > Javier, > > > > Javier Valencia, PE > > 14315 S. Twilight Ln. > > Olathe, KS 66062 > > Office: 913-829-0888 > > Cell: 913-915-3137 > > > -- For group guidelines, visit http://www.rbase.com/support/usersgroup_guidelines.php --- You received this message because you are subscribed to the Google Groups "RBASE-L" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/rbase-l/cb66dca9-1c71-4719-9c65-ecad93f5c3dco%40googlegroups.com.
