HMGSCRIPT: The beginning...

Moderator: Rathinagiri

User avatar
raumi75
Posts: 135
Joined: Wed Dec 17, 2008 2:31 am
Location: Lünen, Germany
Contact:

Re: HMGSCRIPT: The beginning...

Post by raumi75 » Wed Jan 14, 2009 7:12 am

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

User avatar
apais
Posts: 256
Joined: Fri Aug 01, 2008 6:03 pm
Location: uruguay
Has thanked: 23 times
Been thanked: 15 times
Contact:

Post by apais » Wed Jan 14, 2009 1:00 pm

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

User avatar
Rathinagiri
Posts: 5160
Joined: Tue Jul 29, 2008 6:30 pm
DBs Used: MariaDB, SQLite, SQLCipher and MySQL
Location: Sivakasi, India
Has thanked: 127 times
Been thanked: 128 times
Contact:

Post by Rathinagiri » Wed Jan 14, 2009 1:50 pm

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.
East or West HMG is the Best.
South or North HMG is worth.
...the possibilities are endless.

User avatar
Roberto Lopez
HMG Founder
Posts: 3899
Joined: Wed Jul 30, 2008 6:43 pm
Has thanked: 13 times
Been thanked: 135 times

Post by Roberto Lopez » Wed Jan 28, 2009 1:57 pm

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.
Regards/Saludos,

Roberto


(Veritas Filia Temporis)

User avatar
Rathinagiri
Posts: 5160
Joined: Tue Jul 29, 2008 6:30 pm
DBs Used: MariaDB, SQLite, SQLCipher and MySQL
Location: Sivakasi, India
Has thanked: 127 times
Been thanked: 128 times
Contact:

Post by Rathinagiri » Wed Jan 28, 2009 6:36 pm

Thanks for your explanation Roberto.
East or West HMG is the Best.
South or North HMG is worth.
...the possibilities are endless.

User avatar
raumi75
Posts: 135
Joined: Wed Dec 17, 2008 2:31 am
Location: Lünen, Germany
Contact:

Post by raumi75 » Sun Feb 01, 2009 9:07 am

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

User avatar
Roberto Lopez
HMG Founder
Posts: 3899
Joined: Wed Jul 30, 2008 6:43 pm
Has thanked: 13 times
Been thanked: 135 times

Post by Roberto Lopez » Sun Feb 01, 2009 5:00 pm

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.
Regards/Saludos,

Roberto


(Veritas Filia Temporis)

User avatar
Rathinagiri
Posts: 5160
Joined: Tue Jul 29, 2008 6:30 pm
DBs Used: MariaDB, SQLite, SQLCipher and MySQL
Location: Sivakasi, India
Has thanked: 127 times
Been thanked: 128 times
Contact:

Post by Rathinagiri » Mon Feb 02, 2009 3:37 am

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.
East or West HMG is the Best.
South or North HMG is worth.
...the possibilities are endless.

User avatar
Roberto Lopez
HMG Founder
Posts: 3899
Joined: Wed Jul 30, 2008 6:43 pm
Has thanked: 13 times
Been thanked: 135 times

Post by Roberto Lopez » Mon Feb 02, 2009 4:10 pm

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.
Regards/Saludos,

Roberto


(Veritas Filia Temporis)

User avatar
raumi75
Posts: 135
Joined: Wed Dec 17, 2008 2:31 am
Location: Lünen, Germany
Contact:

Post by raumi75 » Tue Feb 03, 2009 4:26 pm

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

Post Reply