Database access from inside serverside scrips

[Andreas Thölke]

hi all!

how can i access the SMUS Database from inside serverside scrips.
something like

gDispatcher.pServer.system.DBPlayer.getAttribute( #attributeName )

i thought. but this does not work.

thanks in advance
andreas

[alchemist]

Amazing how such a simple thing be such a pain when undocumented.
Many questions about that have been post in the past. Yet, all you have to
do is something like the following:

callResult=movie.SendMessage(
"system.DBApplication.getAttribute","system.script.subject",[#application:"m
yApp",#attribute:[#myAttrib]])

in other words, you have to use a command structure like the one you are
using with the MUSXtra clientside, which, when called, returns the value
immediatelly!
Troubled me as well quite a lot in the past to figured it out, i have to
admit.

-alchemist-

"Andreas Thölke" <andreas...@picnicindustries.com> wrote in message
news:adklbj$f4k$1...@forums.macromedia.com...

[Andreas Thölke]

.. cool! so i can use all the client commands on the server as well, but
dont need callbacks.

i would feel better, if it were a normal lingo function call not a message
sent inside the server. i want to do querys to the DB and sort a highscore
table by serverside script. i am excited about the performace ...

> Troubled me as well quite a lot in the past to figured it out, i have to
> admit.

much better documentation is needed on this SW!!

thanks a lot!
andreas

[alchemist]

Actually, it is a "normal lingo function that is called inside the server",
with a somehow "abnormal" syntax. Or at least, it certainly acts as one,
where speed is concearned. What the command does is instruct the movie
object to return to provide to the server script the requested value.
And, though it seems a bit unorthodox "syntax-wise", i believe you'll find
it rather handy in certain occations. One of them would be for instance if
you create an admin movie, test and debug it in director, and then copy it's
scripts to an .ls file to be executed server side - personally, i prefare
this approach by far, rather than writting code in notepad and trying to
debug it from the SMUS.

As for the documentation, I couldn't agree more. Though, basically, all that
needs to be done is just to combine the documentation provided with the
package, with the additional docs posted (like server object model), plus a
few things from the post into a descent help file (.hlp, .hlp, .hlp,
please!!!)

-alchemist-

"Andreas Thölke" <andreas...@picnicindustries.com> wrote in message

news:adm7q5$3jh$1...@forums.macromedia.com...

[Andreas Thölke]

sounds sensible! beeing able to exchange code from the client to the server
and back is a strong argument. and debuggung multiuser stuff can really
become an issue.

i would like to have a book like: "SMUS the definite guide" or "SMUS
Sorcery".

"alchemist" <cha...@stage7.gr> schrieb im Newsbeitrag
news:adnlet$d0p$1...@forums.macromedia.com...