7.6.3.30314 We are stuck there until we can take our system down to move to the new indexing scheme of the later versions.
We have done further testing. On the same computer if I log in as me it works. If I log in as another user it does not. I think the issue must be access rights to the SQL database. We will find it! Thanks to all who have responded. It helps a lot to know what isn't broken! Of course, if anyone else has fixed a similar issue, or knows why I am barking up the wrong tree, please holler. Dennis McGrath -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of MikeB Sent: Tuesday, April 14, 2009 12:51 PM To: RBASE-L Mailing List Subject: [RBASE-L] - RE: Compiler Dennis, What Compiler version are you using? ----- Original Message ----- From: "Dennis McGrath" <[email protected]> To: "RBASE-L Mailing List" <[email protected]> Sent: Tuesday, April 14, 2009 1:47 PM Subject: [RBASE-L] - RE: Compiler Thanks Paul. I'll double check that the DSN's are System. What ODBC driver are you using? Dennis ________________________________ From: [email protected] [mailto:[email protected]] On Behalf Of Paul Buckley Sent: Tuesday, April 14, 2009 12:42 PM To: RBASE-L Mailing List Subject: [RBASE-L] - RE: Compiler Dennis, I have a 7.6 compiled app that has been running for a couple of years that accesses a SQL database. Like yourself, I have the SQL tables attached permanently in Rbase and I use a System DSN on each workstation. They don't even have a license of Rbase in house and I have no problems accessing data. I can read from and write to the SQL tables. Paul Buckley From: [email protected] [mailto:[email protected]] On Behalf Of Dennis McGrath Sent: Tuesday, April 14, 2009 1:31 PM To: RBASE-L Mailing List Subject: [RBASE-L] - RE: Compiler We cannot execute the SATTACH at run time because we run with staticdb on. If we did so, the data would be created as a temporary tables and we have found that to be way slow as the source data is very large. We have the foreign tables SATTACHED permanently. We do create the DSN on each computer. Perhaps we should try creating the permanent connections DSN-Less, although I can't imagine why this would make a difference. ________________________________ From: [email protected] [mailto:[email protected]] On Behalf Of Javier Valencia Sent: Tuesday, April 14, 2009 12:19 PM To: RBASE-L Mailing List Subject: [RBASE-L] - RE: Compiler Dennis: I have no problems accessing other databases from a compiled application using DSN-less connections, where the SCONNECT and SATTACH as well as the SDETACH and SDISCONNECT are executed at run time. You would have this issue only if the application is trying to access another R:Base database as the Compiler and/or Compiled applications do not install the R:Base ODBC driver; this driver is installed only when the full version of R:Base is installed. However, if you are accessing a SQL Server, you should not have this problem provided you have the SQL drivers properly installed. Ironic that you can readily access other databases from a compiled application but to access another R:Base database you have to use Oterro...oh well... Javier, Javier Valencia 913-915-3137 ________________________________ From: [email protected] [mailto:[email protected]] On Behalf Of Dennis McGrath Sent: Tuesday, April 14, 2009 11:16 AM To: RBASE-L Mailing List Subject: [RBASE-L] - Compiler I'm having an issue with the compiler. Perhaps someone has a fix. I have a DB with sattached tables (actually views) from SQL Server. Running the same compiled EXE (starting in the EXE directory with -A switch) On some computers the data is available, on others no rows are returned. The pattern seems to be if full RBASE 7.6 is installed the data is available, otherwise not. Thanks for any feedback, Dennis McGrath --- RBASE-L ================================================ TO POST A MESSAGE TO ALL MEMBERS: Send a plain text email to [email protected] (Don't use any of these words as your Subject: INTRO, SUBSCRIBE, UNSUBSCRIBE, SEARCH, REMOVE, SUSPEND, RESUME, DIGEST, RESEND, HELP) ================================================ TO SEE MESSAGE POSTING GUIDELINES: Send a plain text email to [email protected] In the message SUBJECT, put just one word: INTRO ================================================ TO UNSUBSCRIBE: Send a plain text email to [email protected] In the message SUBJECT, put just one word: UNSUBSCRIBE ================================================ TO SEARCH ARCHIVES: Send a plain text email to [email protected] In the message SUBJECT, put just one word: SEARCH-n (where n is the number of days). In the message body, place any text to search for. ================================================
