Re: DB Access in standalones
Previously, Trevor DeVore <[EMAIL PROTECTED]> said: At first, program.rev would simply start using database.rev and that worked fine in the Rev development environment. When I built the standalone this wouldn't work though. I then added a line which would start using splash.rev (the rev file that was part of the executable) and then everything started working great. I assume that the splash.rev file had the links to the database external and by using it as a library in program.rev it made the database functionality available to it. Hope this helps. I tried this, too, but there was no change in behavior. To reprise: my main stack, which basically is a splash and login screen, comes up. I am able to authenticate a user against the mySQL database. In fact I can keep logging in various users and even add users to the db from my login card. But when I go to the substack, which presents a series of quizzes whose items are pulled from an item bank in the db, all database accesses fail. Then if I go back to the main stack login card, I can no longer access the database, but get a 'dberror, invalid database type' error. Strangely enough, this error (I think) is returned by the db library, so apparently my stack is still finding it. Hey Rev team! Anyone following this? Help us out here; this is a major problem. Devin Asay Humanities Technology and Research Support Center Brigham Young University ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: DB Access in standalones
> Message: 8 > Date: Tue, 19 Aug 2003 23:09:10 -0500 > From: "J. Landman Gay" <[EMAIL PROTECTED]> > Organization: HyperActive Software > To: [EMAIL PROTECTED] > Subject: Re: DB Access in standalones > Reply-To: [EMAIL PROTECTED] > > On 8/19/03 6:06 PM, Trevor DeVore wrote: > > > I had problems with database access in standalones at one point but was able to get everything working. Here is how my project is set up- > > > > 1) I have one splash stack whic his used to create the executable (splash.rev) > > 2) The main program (program.rev) and two additional pop-up windows are .rev files stored external to the executable. > > 3) The main program has a sub stack which has all of the database calls (database.rev). > > 4) When the executable launches it opens program.rev and hides itself. > > > > At first, program.rev would simply start using database.rev and that worked fine in the Rev development environment. When I built the Well one thing that you can try is to insert the script of the stack that has the externals property into front, or back. Currently what's happening is that Rev sets the externals in the dev environment in such a way that it is available to all stacks...so it works in dev but may not work in standalones. The team is working to resolve these issues..but if you have a recipe and can send sample stacks please send to bugzilla and mark them something of high priority if they interfare with you using RevDB. Tuviah Snyder <[EMAIL PROTECTED]> <http://www.runrev.com/> Runtime Revolution Limited - Software at the Speed of Thought ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: DB Access in standalones
On 8/19/03 11:28 PM, Monte Goulding wrote: The Dist Builder sets the externals property of the standalone stack for you during the build so you don't need to do anything except make sure that the destroyStack of the standalone stack (splash) isn't true. Externals exit when the stack they are referenced from is removed from memory. That's what I figured, it is good to get confirmation. When I said the externals were set on the mainstack, I meant that I was letting Rev do that. I did try setting them myself once, but the distribution builder changed them anyway so I quit trying. The destroystack of the splash/standalone is false, but even so, I'm no longer closing it. Still doesn't work though. Did anyone try Chris' database test? -- Jacqueline Landman Gay | [EMAIL PROTECTED] HyperActive Software | http://www.hyperactivesw.com ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: DB Access in standalones
On 8/19/03 11:33 PM, Trevor DeVore wrote: The splash stack hides itself and opens the program.rev file which is in the data folder. In the preOpenStack handler of program.rev I start using the splash stack and the database stack. Using the rev database functions works properly this way. I remember having to try A LOT of different combinations before I came across this one. It even stumped the Rev tech support people. That's exactly how I set it up, but no go. Maybe there is something else wrong besides just the externals. -- Jacqueline Landman Gay | [EMAIL PROTECTED] HyperActive Software | http://www.hyperactivesw.com ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: DB Access in standalones
On 8/19/03 J. Landman Gay wrote> >I had great hopes for this, but it didn't work. What handler did you put >the "start using" command into? I tried putting it into the preOpenStack >script of the splash stack. Technically we should never have to "start >using" the mainstack in a standalone because its scripts are always in >use anyway, so if this worked for you it is an unusual requirement. But >I carried on. > >My stack setup is nearly identical to yours. Splash stack becomes the >standalone mainstack, DB libs in a substack. The externals property is >set on the mainstack. I was previously closing the main stack before >going to another stack, and your hint made me think this could be the >problem. I think (but am not sure) that closing a stack removes its >externals from memory. So I left the mainstack open as well as started >using it. Still didn't work though. The splash stack hides itself and opens the program.rev file which is in the data folder. In the preOpenStack handler of program.rev I start using the splash stack and the database stack. Using the rev database functions works properly this way. I remember having to try A LOT of different combinations before I came across this one. It even stumped the Rev tech support people. -- Trevor DeVore Blue Mango Multimedia [EMAIL PROTECTED] ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
RE: DB Access in standalones
> I had great hopes for this, but it didn't work. What handler did you put > the "start using" command into? I tried putting it into the preOpenStack > script of the splash stack. Technically we should never have to "start > using" the mainstack in a standalone because its scripts are always in > use anyway, so if this worked for you it is an unusual requirement. But > I carried on. > > My stack setup is nearly identical to yours. Splash stack becomes the > standalone mainstack, DB libs in a substack. The externals property is > set on the mainstack. I was previously closing the main stack before > going to another stack, and your hint made me think this could be the > problem. I think (but am not sure) that closing a stack removes its > externals from memory. So I left the mainstack open as well as started > using it. Still didn't work though. > Hi The Dist Builder sets the externals property of the standalone stack for you during the build so you don't need to do anything except make sure that the destroyStack of the standalone stack (splash) isn't true. Externals exit when the stack they are referenced from is removed from memory. Regards Monte ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: DB Access in standalones
On 8/19/03 6:06 PM, Trevor DeVore wrote: I had problems with database access in standalones at one point but was able to get everything working. Here is how my project is set up- 1) I have one splash stack whic his used to create the executable (splash.rev) 2) The main program (program.rev) and two additional pop-up windows are .rev files stored external to the executable. 3) The main program has a sub stack which has all of the database calls (database.rev). 4) When the executable launches it opens program.rev and hides itself. At first, program.rev would simply start using database.rev and that worked fine in the Rev development environment. When I built the standalone this wouldn't work though. I then added a line which would start using splash.rev (the rev file that was part of the executable) and then everything started working great. I assume that the splash.rev file had the links to the database external and by using it as a library in program.rev it made the database functionality available to it. Hope this helps. I had great hopes for this, but it didn't work. What handler did you put the "start using" command into? I tried putting it into the preOpenStack script of the splash stack. Technically we should never have to "start using" the mainstack in a standalone because its scripts are always in use anyway, so if this worked for you it is an unusual requirement. But I carried on. My stack setup is nearly identical to yours. Splash stack becomes the standalone mainstack, DB libs in a substack. The externals property is set on the mainstack. I was previously closing the main stack before going to another stack, and your hint made me think this could be the problem. I think (but am not sure) that closing a stack removes its externals from memory. So I left the mainstack open as well as started using it. Still didn't work though. -- Jacqueline Landman Gay | [EMAIL PROTECTED] HyperActive Software | http://www.hyperactivesw.com ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: DB Access in standalones
Hi guys I've been following this thread with interest since I use val with RR. I call vxcmd directly, not through the RR db libraries. However, like Jacque, I have also experienced difficulties with setting the external at startup. It may very well be my lack of coding ability, but it works in the ide and doesn't work in a standalone, so I think it may be something else. I've tried to get it to happen consistently so that I can report it. I guess I can't add anything constructive here except that there may be loading issues with vxcmd as well as with the supplied libraries. Ron > >> When I connect directly to the Valentina XCMD using Valentina calls, >> everything works fine for me; I recommend that until this situation on >> DB access in standalones is fixed/resolved by RunRev that those who need >> to work with Valentina just call the XCMD directly. > > That's been my experience too, using Valentina in MetaCard. > Unfortunately those stacks that start out in Revolution have no access > to the same external. Rev ships with an unusual combination of drivers > in one folder and the externals in a separate .bundle (on OS X). I > couldn't find any way to use them that way (I tried to use MC to build a > standalone with them, but I couldn't get it to work.) I believe that the > downloadable external at Valentina's site has the drivers built into the > same file, while Rev splits them out separately. > > Actually some of the main info I want to know from the Rev team is what > that .bundle does, what the drivers do, what are their required relative > locations on disk, and what relationship one has with the other. ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: DB Access in standalones
On 8/19/03 5:29 PM, Ken Ray wrote: When I connect directly to the Valentina XCMD using Valentina calls, everything works fine for me; I recommend that until this situation on DB access in standalones is fixed/resolved by RunRev that those who need to work with Valentina just call the XCMD directly. That's been my experience too, using Valentina in MetaCard. Unfortunately those stacks that start out in Revolution have no access to the same external. Rev ships with an unusual combination of drivers in one folder and the externals in a separate .bundle (on OS X). I couldn't find any way to use them that way (I tried to use MC to build a standalone with them, but I couldn't get it to work.) I believe that the downloadable external at Valentina's site has the drivers built into the same file, while Rev splits them out separately. Actually some of the main info I want to know from the Rev team is what that .bundle does, what the drivers do, what are their required relative locations on disk, and what relationship one has with the other. -- Jacqueline Landman Gay | [EMAIL PROTECTED] HyperActive Software | http://www.hyperactivesw.com ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: DB Access in standalones
I had problems with database access in standalones at one point but was able to get everything working. Here is how my project is set up- 1) I have one splash stack whic his used to create the executable (splash.rev) 2) The main program (program.rev) and two additional pop-up windows are .rev files stored external to the executable. 3) The main program has a sub stack which has all of the database calls (database.rev). 4) When the executable launches it opens program.rev and hides itself. At first, program.rev would simply start using database.rev and that worked fine in the Rev development environment. When I built the standalone this wouldn't work though. I then added a line which would start using splash.rev (the rev file that was part of the executable) and then everything started working great. I assume that the splash.rev file had the links to the database external and by using it as a library in program.rev it made the database functionality available to it. Hope this helps. -- Trevor DeVore Blue Mango Multimedia [EMAIL PROTECTED] ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
RE: DB Access in standalones
I hate to mention this, but I've been using Valentina for over 6 months now and decided not to use the Rev libraries to connect to or implement my use of the database. (For those who are wondering why, my main reason is that I need to do a lot with manipulating data inside of a cursor and posting that data back to the Valentina DB, plus creating/modifying tables on the fly, which Rev's functions don't cover very well.) When I connect directly to the Valentina XCMD using Valentina calls, everything works fine for me; I recommend that until this situation on DB access in standalones is fixed/resolved by RunRev that those who need to work with Valentina just call the XCMD directly. Just my 2 cents, Ken Ray Sons of Thunder Software Email: [EMAIL PROTECTED] Web Site: http://www.sonsothunder.com/ > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of > J. Landman Gay > Sent: Tuesday, August 19, 2003 3:00 PM > To: [EMAIL PROTECTED] > Subject: Re: DB Access in standalones > > > On 8/19/03 1:21 PM, Devin Asay wrote: > > > What is the real story here? The documentation is not very > detailed on > > this point, and in fact does not seem to reflect what's really > > happening. Can someone on the Rev team explain it to me? > Tuviah? Geoff? > > I really need to get this application up soon. Thanks. > > I would also appreciate an explanation from someone who > knows. After I > answered you yesterday, I spent almost five hours wrestling > with exactly > the same problem. I never could get the external to load > properly. Like > you, I tried a startup handler that called > revSetDatabaseDriverPath but > it did no good. I also moved all the scripts from a substack that > contained the DB calls into the main stack script but that > didn't help > either. I tinkered with scripts endlessly and probably built 40 or 50 > trial standalones, none of which worked. The stack works fine > in the IDE. > > This should not be so hard, and I suspect there is a problem > with either > the engine or the distribution builder. I did find an error in Rev's > database library scripts which I thought could be the problem, but > fixing it still didn't cause the externals to load for me. > > Even so, you will probably want to try fixing Rev's DB > library script. > It's in the stack called "revlibrary.rev", which contains a > group that > gets copied to your standalone during a build. You'll need to > edit the > script of the group called "revLibraries" which contains a > preOpenBackground handler. That handler starts out like this: > > on preOpenBackGround >repeat with i = 1 to the number of btns in me > if the short name of button i is among the items of > "revTable,revDatabase" then >insert script of button i of me into front > else >insert script of btn i of me into back > end if >end repeat > > If this group isn't the first one placed on the card in the > standalone, > the script will fail to insert the database lib scripts in > some cases, > and will insert non-database button scripts arbitrarily from other > buttons in your stack. If that happens, all Rev-related > database calls > will fail. The fix is to change line 3 to this: > > if the short name of button i OF ME is among the items of > "revTable,revDatabase" then > > This ensures that the right set of button scripts are > inserted. (It took > me forever to find this bug, since you can't look at the > group's script > once it is in a standalone.) I've bug-reported it and Runtime > fixed it > yesterday, but people will probably want to alter their > current copies > of the library to accomodate until the next release comes out. > > I thought this fix was the clincher and things would work > properly after > that, but as I said, the external still didn't load even with the > revised library script. I am not at liberty to send Runtime > the stacks I > am working on, but if you can send them yours, I hope you > will. It seems > to be a common problem for many of us and I'd like to see it resolved > soon. As near as I can tell, there are some stacks which > simply cannot > use the database externals in OS X. > > -- > Jacqueline Landman Gay | [EMAIL PROTECTED] > HyperActive Software | http://www.hyperactivesw.com > > ___ > use-revolution mailing list > [EMAIL PROTECTED] > http://lists.runrev.com/mailman/listinfo/use-> revolution > ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: DB Access in standalones
On 8/19/03 1:21 PM, Devin Asay wrote: What is the real story here? The documentation is not very detailed on this point, and in fact does not seem to reflect what's really happening. Can someone on the Rev team explain it to me? Tuviah? Geoff? I really need to get this application up soon. Thanks. I would also appreciate an explanation from someone who knows. After I answered you yesterday, I spent almost five hours wrestling with exactly the same problem. I never could get the external to load properly. Like you, I tried a startup handler that called revSetDatabaseDriverPath but it did no good. I also moved all the scripts from a substack that contained the DB calls into the main stack script but that didn't help either. I tinkered with scripts endlessly and probably built 40 or 50 trial standalones, none of which worked. The stack works fine in the IDE. This should not be so hard, and I suspect there is a problem with either the engine or the distribution builder. I did find an error in Rev's database library scripts which I thought could be the problem, but fixing it still didn't cause the externals to load for me. Even so, you will probably want to try fixing Rev's DB library script. It's in the stack called "revlibrary.rev", which contains a group that gets copied to your standalone during a build. You'll need to edit the script of the group called "revLibraries" which contains a preOpenBackground handler. That handler starts out like this: on preOpenBackGround repeat with i = 1 to the number of btns in me if the short name of button i is among the items of "revTable,revDatabase" then insert script of button i of me into front else insert script of btn i of me into back end if end repeat If this group isn't the first one placed on the card in the standalone, the script will fail to insert the database lib scripts in some cases, and will insert non-database button scripts arbitrarily from other buttons in your stack. If that happens, all Rev-related database calls will fail. The fix is to change line 3 to this: if the short name of button i OF ME is among the items of "revTable,revDatabase" then This ensures that the right set of button scripts are inserted. (It took me forever to find this bug, since you can't look at the group's script once it is in a standalone.) I've bug-reported it and Runtime fixed it yesterday, but people will probably want to alter their current copies of the library to accomodate until the next release comes out. I thought this fix was the clincher and things would work properly after that, but as I said, the external still didn't load even with the revised library script. I am not at liberty to send Runtime the stacks I am working on, but if you can send them yours, I hope you will. It seems to be a common problem for many of us and I'd like to see it resolved soon. As near as I can tell, there are some stacks which simply cannot use the database externals in OS X. -- Jacqueline Landman Gay | [EMAIL PROTECTED] HyperActive Software | http://www.hyperactivesw.com ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: DB Access in standalones
I wrote Monday about my problems trying to get my standalone to connect to a mySQL database: the standalone does not successfully contact the database. Instead I get a revdberr, invalid database type. (I chose to include error messages during distribution building. Jan provided a useful clue: On Tuesday, August 19, 2003, at 12:45 AM, Jan Schenkel <[EMAIL PROTECTED]> wrote: You might want to check out the Transcript dictionary entry for the 'revSetDatabaseDriverPath' command. What I did was use the startup handler to 1) set the defaultFolder to the folder containing the main stack, then 2) use the revSetDatabaseDriverPath command to set the database driver path to the defaultFolder. In OS X this happens to be in the App bundle/Contents/MacOS/. Now when I do this I can contact the database successfully as long as I remain in the main stack. As soon as I go to a substack (where most of the queries take place) it stops working. Even when I go back to the main stack the database queries no longer work. I am back to the situation where I get a revdberr, invalid database type error. This sounds a lot like what Jacque wrote about: On Tuesday, August 19, 2003, at 12:47 AM, "J. Landman Gay" <[EMAIL PROTECTED]> wrote: Is the externals property set to the right path? The externals property is relative to the application bundle, not the engine inside the Contents folder. That's probably why Rev puts it where you first found it. I believe Rev also tries to set the externals property during a build. If you moved the files, the path that Rev sets would no longer be accurate (and it produces a silent error in that case.) This sounds a lot like the problems I've had loading externals, which has almost always been a problem with paths during startup. Also, if it applies, it seems to help to keep all the database calls in the mainstack rather than in substacks. There seems to be some problem with substacks that make calls to externals. If I insert an answer dialog in the standalone to report the externals property, it says "revdb.bundle", which, as Jacque said, supposedly means relative to the application bundle. I take this to mean inside the app bundle, but the Distribution Builder puts it at the same level as the app bundle. What is the real story here? The documentation is not very detailed on this point, and in fact does not seem to reflect what's really happening. Can someone on the Rev team explain it to me? Tuviah? Geoff? I really need to get this application up soon. Thanks. Devin Asay Humanities Technology and Research Support Center Brigham Young University ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: DB Access in standalones
On 8/18/03 3:04 PM, Devin Asay wrote: One puzzling thing: The standalone gets built with two folders in the same folder as the application package: database_drivers and revdb.bundle. I thought this was strange, because I'd understood that the db libraries were supposed to be put into the app package. So I moved them into the package. Now when I launch the app and try to connect to the database, it still fails, but I don't get the error message. Is the externals property set to the right path? The externals property is relative to the application bundle, not the engine inside the Contents folder. That's probably why Rev puts it where you first found it. I believe Rev also tries to set the externals property during a build. If you moved the files, the path that Rev sets would no longer be accurate (and it produces a silent error in that case.) This sounds a lot like the problems I've had loading externals, which has almost always been a problem with paths during startup. Also, if it applies, it seems to help to keep all the database calls in the mainstack rather than in substacks. There seems to be some problem with substacks that make calls to externals. -- Jacqueline Landman Gay | [EMAIL PROTECTED] HyperActive Software | http://www.hyperactivesw.com ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: DB Access in standalones
--- Devin Asay <[EMAIL PROTECTED]> wrote: > I am building a standalone for OS X 10.2.6 (Rev v. > 2.0.2, Commercial > Enterprise license). The app uses database calls to > a mysql database on > my file server. In the development environment it > works perfectly. I > built an OS X distribution, taking care to include > the db libraries. > However, the standalone does not successfully > contact the database. > Instead I get a revdberr, invalid database type. (I > chose to include > error messages during distribution building. > > One puzzling thing: The standalone gets built with > two folders in the > same folder as the application package: > database_drivers and > revdb.bundle. I thought this was strange, because > I'd understood that > the db libraries were supposed to be put into the > app package. So I > moved them into the package. Now when I launch the > app and try to > connect to the database, it still fails, but I don't > get the error > message. > > Can anyone point me in the right direction? > > Devin Asay > Hi Devin, You might want to check out the Transcript dictionary entry for the 'revSetDatabaseDriverPath' command. If that doesn't cut it, insert an 'answer' with all your connection parameters to make sure they're up to sniff. Hope this helped, Jan Schenkel. = "As we grow older, we grow both wiser and more foolish at the same time." (La Rochefoucauld) __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
