QM - PureBasic - SpiderBASIC

[Cleber Vieira Baptista]

Hi,

http://www.purebasic.fr
http://www.spiderbasic.com/

PB managed to connect with QM, now I'm trying to SB, has a very similar syntax to the PB,
are from the same company.

The SB code is changed to JavaScript to run on browsers.

I have no experience with PB or SB, have little experience with QM and no experience with web systems.

When I compile qmclient.unicode.pb to qmclient.unicode.sb gave error uses the \qmsys\ bin\qmclilib.dll

Procedure OpenQMClientLibrary()
   If QMLib = 0
      CompilerSelect #PB_Compiler_OS
        CompilerCase #PB_OS_Linux
           LibPath$ = "/usr/qmsys/bin/qmclilib.so"
        CompilerCase #PB_OS_Windows
           LibPath$ = "\qmsys\bin\qmclilib.dll"
      CompilerEndSelect

      QMLib = OpenLibrary(#PB_Any, LibPath$)  <<<<<<<[17:33:56] [COMPILER] Line 53: OpenLibrary() is not a function (or not available in demo version), array, list, map or macro.

      If QMLib = 0
         PrintN("Cannot open " + LibPath$)
         End
      EndIf
   EndIf
EndProcedure

SB forum: http://forums.spiderbasic.com/viewtopic.php?f=6&t=371 I received this response:

"You cannot open a library on client side (in the Webbrowser) with JavaScript for security reasons."

Anyone have any suggestions?

Att.,

--

Cleber Vieira Baptista

+55

 61 8441-1663 Oi

 83 8725-9988 Oi

[Kevin Powick]

As Peter said on the SB web forum, you cannot use JavaScript in a browser to call/open a client side library. 

Instead of telling us what you're trying to "make work", explain what you ultimately want to accomplish.  e.g. I want to build a website that can display/update information found in my QM database.

Knowing what you want to accomplish will allow people to provide relevant suggestions.

--
Kevin Poiwck

[Cleber Vieira Baptista]

Hi Kevin,

It seems obvious :) 

I want to build a website that can display/update information found in my QM database.

I will not be able to make a web site connect with QM using qmclilib.so or qmclilib.dll? I'll have to use a CGI?

att.,

Cleber

--
You received this message because you are subscribed to
the "Pick and MultiValue Databases" group.
To post, email to: mvd...@googlegroups.com
To unsubscribe, email to: mvdbms+un...@googlegroups.com
For more options, visit http://groups.google.com/group/mvdbms

[Kevin Powick]

On Thursday, 28 May 2015 19:07:20 UTC-4, Cleber wrote:

It seems obvious :) 

Not from your original message.

 

I will not be able to make a web site connect with QM using qmclilib.so or qmclilib.dll? I'll have to use a CGI?

CGI is an option, but so is using the QM Libraries.  There are several ways to approach the problem.

Personally, I would make my website agnostic to the "back end" database by writing some middleware to handle HTTP requests between the website (or web page using ajax) and the database.  The middleware would expose an "RESTful" API to the website and use your database libraries of choice to "talk" to the database.

[website/webpage] <--http/json/xml--> <--API--> [middleware] <--dbLib--> [database]

What you use for the language to write your middleware is pretty much up to you, but you would be best off writing it in something with good libraries for HTTP, JSON, and/or XML.  Data exchange between the website (or web page using AJAX requests) and your middleware should use a common format such as JSON or XML, as these are the most common standards for data exchange.

There are several added benefits to this approach.

1) The "front end" isn't limited to a website or web page.  Any "client" capable of HTTP requests could "talk" to your database via the API exposed by your middleware.  This includes regular Windows programs, smartphones, tablets, etc.

2) The database can be swapped-out for a different vendor's and it makes no difference to your end-users.  e.g. You could switch from QM to SQL Server and nothing on the development side of your website, or any other clients consuming your database services, would have to change.

3) You web server, middleware, and database do not have to reside on the same physical machine, or even the same physical network.  This can be very handy if your website is being hosted by a service provider that would not allow you to install your own software or does not support your database of choice.

That's a general overview of my preferred approach.  The technical details of implementing such an approach is beyond what I'm prepared to type out.  It's been discussed here several times over the years here.  Google is your friend. ;)

Regards,

--

Kevin Powick