HMGforum.com

rathinagiri wrote:Actually, Roberto has told earlier somewhere in our forum that, HMGScript will utilize MySQL as the back end database.

Of course I have seen that. And it seems to be the right choice. What I am trying to say is, that MySQL must be more than a datastore. A Harbour program needs to be rewritten to make use of the power of SQL (my examples above). Or will there be an automatic SQL-Generator within HMGSCRIPT?

Raumi75

It's all to be done. But I think Roberto's idea is working on recordsets and treat then as dbfs on the javascript side. Still you'll need selects inserts and updates to be done manually but it is not really difficult and they have all the advantages you've pointed out.

Brgrds
Angel

Even now, we can integrate HMG and MySQL. Isn't it?

Then will that be a big problem, if we port this to javascript?

As you had said, the bandwidth would be the hindrance. I think that would be taken care of.

raumi75 wrote:

rathinagiri wrote:Actually, Roberto has told earlier somewhere in our forum that, HMGScript will utilize MySQL as the back end database.

Of course I have seen that. And it seems to be the right choice. What I am trying to say is, that MySQL must be more than a datastore. A Harbour program needs to be rewritten to make use of the power of SQL (my examples above). Or will there be an automatic SQL-Generator within HMGSCRIPT?

Raumi75

When referred to database handling, I've mentioned php scripts to handle it.

So, the basic idea, is not to port seek() function to JavaScript. The idea is that JavaScript version of seek() call to a php script that do the job and return the results.

The same is applicable for all other database functions.

Of course, all of these scripts must be generic and an integral part of HMGSCRIPT, so the programmer should not to care about it.

Regards,


Regards,

Roberto.

Thanks for your explanation Roberto.

Hello Roberto,

Great to hear from you on this topic. I will try HMGScript real soon.

I am sure you will find a good way to make the SQL-access easy in Clipper-Way. But the dbase -pradigm is a lot different from sql-paradigm. When porting an old application, I found that sometimes one line of SQL-Statement is worth a thousand words in clipper. I replaced many lines of clipper-code with SQL, that get passed to the sql-server.

Maybe it would not be so bad after all to let the programmer write parts in sql.

For others, automatic creation of SQL will be great. Have you taken a look at the pear-database abstraction layer (http://pear.php.net/package/MDB2)? It does a good job managing SQL-Access and other pear-packages like the datagrid use them as a plugin.

It also offers one really big advantage: it is RDBMS undependent. So you don't have to decide at such an early stage, if you want to use MySQL or a different program.

I personally prefer postgresql over mysql, because it offers a lot more functionality, but of course mysql is more important, because it has a huge installation base.

I am very excited what your solution will look like!

Raumi75

raumi75 wrote:Hello Roberto,

Great to hear from you on this topic. I will try HMGScript real soon.
<...>
I am very excited what your solution will look like!

Raumi75

At this moment I already have a very basic working model, but I've not finished the xBase layer yet.

In this first, experimental version, dbUseArea will need a unique parameter: A SQL query.

This query is sent via xmlhttprequest to a php script in the server, that returns the resulting recordset as delimited text.

The text is parsed via the 'split' method and converted in a two dimensional array.

I've already completed a very basic versions of these functions:

- dbusearea()
- recno()
- dbgoto()
- dbgotop()
- dbgobottom()
- dbskip()
- eof()
- bof()
- lastrec()
- reccount()
- fieldget()
- fcount()

I've already created a non-xBase function:

DefineConnection(cConnectionName,cServer,cUser,cPassWord,cDataBase)

To set connection parameters.

Prior to release the code I must complete the following functions:

- dbsetorder()
- dbseek()
- found()

When ready, I'll publish it.

Until now, the results are very promising. It performs very fast.

About paradigms, you are right. Basically, the true problem is the recordset size.

This is the reason I've decided to use a query as parameter to dbusearea(). This way the programmer will be responsible for the size of the data transferred from the server to the client.

I'll take a look at 'pear-database' ASAP.

Regards,

Roberto.

Nice to hear Roberto.

After reading your previous messages, I had checked this with our existing HMG. As you said, it is fast enough.

I had written a small php script and HMG counterpart to split the text, returned from the website. I am using '\n' as the delimiter in php and using chr(10) to split the txt data to a two dimensional array in HMG. I will add a working sample today as a separate thread.

Thanks for the idea.

rathinagiri wrote:Nice to hear Roberto.

After reading your previous messages, I had checked this with our existing HMG. As you said, it is fast enough.

I had written a small php script and HMG counterpart to split the text, returned from the website. I am using '\n' as the delimiter in php and using chr(10) to split the txt data to a two dimensional array in HMG. I will add a working sample today as a separate thread.

Thanks for the idea.

At this moment, I'm using \n ans record delimiter and \t as field delimiter.

The only problem with it could arise when such characters be used as field content, but, considering that this is an experimental stage, we can care about that in a future stage.

Regards,

Roberto.

Roberto Lopez wrote: At this moment, I'm using \n ans record delimiter and \t as field delimiter.

The only problem with it could arise when such characters be used as field content, but, .. .

The php-function "addslashes" could prove useful. http://de.php.net/manual/en/function.addslashes.php It will turn \t into \\t. Plus it escapes the ' character, which causes trouble in SQL-Queries.

Jan