FiveTech Support Forums

Hello Alfredo,
Just as a small practical tip:

Using many ?? calls works,
but once the HTML grows, it quickly becomes hard to read and maintain.

A cleaner alternative is to
build the HTML block as a whole using TEXT … ENDTEXT
and output it once at the end.

This way:

the logic remains easy to debug

the HTML reads like HTML

and the code becomes much more maintainable over time

It’s not a requirement and not a dogma,
just an approach that tends to pay off very quickly in web code.

Best regards,
Otto

<?prg

LOCAL o
LOCAL cHtml
LOCAL cTitulo := 'Test MySQL Connection'
LOCAL nAnio   := Year( Date() )
LOCAL cEstadoHtml

// Header laden
?? ULoadHtml( 'examples/sql/header.html', cTitulo )

// --- Logik: MySQL-Verbindung ---
o := WDO_MYSQL():New( ;
      'localhost', ;
      'fivetech_test', ;
      'fivewin2026', ;
      'dbharbour', ;
      3306 )

IF o:lConnect

   TEXT INTO cEstadoHtml
   <div class="mensaje-exito">
     <div class="titulo-mensaje">✓ Conexión Exitosa</div>
     <div class="detalle-mensaje">
       Se ha establecido correctamente la conexión con la base de datos MySQL.<br>
       Estado: <strong>Conectado</strong><br>
       Base de datos: <strong>dbharbour</strong>
     </div>
   </div>
   ENDTEXT

ELSE

   TEXT INTO cEstadoHtml
   <div class="mensaje-error">
     <div class="titulo-mensaje">✗ Error de Conexión</div>
     <div class="detalle-mensaje">
       <strong>No se pudo establecer la conexión con MySQL</strong><br><br>
       Detalles del error:<br>
       <code>${ o:cError }</code><br><br>
       Posibles soluciones:
       <ul>
         <li>Verifica que el servidor MySQL esté ejecutándose</li>
         <li>Confirma que las credenciales sean correctas</li>
         <li>Revisa que la base de datos "dbharbour" exista</li>
         <li>Asegúrate de que el puerto 3306 esté disponible</li>
         <li>Verifica los permisos del usuario en MySQL</li>
       </ul>
     </div>
   </div>
   ENDTEXT

ENDIF

IF o != NIL
   o:Close()
ENDIF

// --- HTML Template ---
TEXT INTO cHtml
<style>
.contenedor { max-width: 800px; margin: 50px auto; padding: 20px; }
.mensaje-error { background-color: #f8d7da; color: #721c24; border: 1px solid #f5c6cb;
  padding: 20px; border-radius: 8px; box-shadow: 0 4px 6px rgba(0,0,0,0.1); margin: 20px 0; }
.mensaje-exito { background-color: #d4edda; color: #155724; border: 1px solid #c3e6cb;
  padding: 20px; border-radius: 8px; box-shadow: 0 4px 6px rgba(0,0,0,0.1); margin: 20px 0; }
.titulo-mensaje { font-size: 20px; font-weight: bold; margin-bottom: 10px; }
.detalle-mensaje { font-size: 16px; line-height: 1.6; }
.footer { margin-top: 50px; padding: 20px; border-top: 1px solid #ddd;
  text-align: right; color: #666; font-size: 12px; }
.info-conexion { background-color: #e7f3ff; border-left: 4px solid #2196F3;
  padding: 15px; margin: 20px 0; border-radius: 4px; }
</style>

<div class="contenedor">

  <div class="info-conexion">
    <strong>Intentando conectar a MySQL...</strong><br>
    Servidor: localhost<br>
    Base de datos: dbharbour<br>
    Usuario: fivetech_test<br>
    Puerto: 3306
  </div>

  ${ cEstadoHtml }

</div>

<div class="footer">
  <strong>Hix is Harbourix</strong><br>
  Harbour Web Server<br>
  Copyright ${ AllTrim( Str( nAnio ) ) } Charly Aubia
</div>
ENDTEXT

// Ausgabe
?? cHtml

RETURN NIL
?>

Gracia otto.

Tiene razón, pero la idea, es que Hix1.2, existe y funciona. Y lo que tenemos poco conocimiento en todo esto de la Web esto es una mejor alternativa, para dar el paso, sin miedo.

Hello Alfredo,
Of course HIX works – just like the earlier mod_harbour versions worked and work.
In my case this approach has been running in production for about five years without issues.

What I personally struggled with at the beginning was the heavy use of concatenating with immediate output (??).
It works perfectly fine from a technical point of view, but once the HTML grows, it can become hard to read and maintain.

That’s why I mentioned it.

A big advantage of building the HTML as a single, coherent block (for example using TEXT … ENDTEXT) is that you can:

copy the generated HTML directly into a simple .html file, such as:

<!DOCTYPE html>
<html>
<head>
<style>
</style>
</head>
<body>

</body>
</html>

test the layout independently of the Harbour program

immediately see whether the HTML structure is correct

and benefit from proper syntax highlighting in the editor, which is a huge help for larger layouts

This is not a requirement and not a criticism of the existing approach –
just a practical experience that makes working with web output much more comfortable as the code grows.

Best regards,
Otto

Gracia Otto.

Buena tarde..

Es posible usa la clase TArrayData para gestionar en memoria las consultas obtenenidas de las consultas SQL o DBF ?

Jonsson Russi

Hello Jonsson,
Yes, you can do that.

You are still working in a normal Harbour program:
you read the data from SQL or DBF and load it into an array or TArrayData to process it in memory.

In a web context, it helps to think of this like an interpreter run:

the Harbour program starts

it reads the data

processes it in memory

and finally produces a string

Everything you want to show in a web browser must be output as a string,
and that string must be formatted according to HTML rules
(for example <table>, <tr>, <td>).

The array (TArrayData) is only a temporary working structure.
The browser never sees the array itself — it only receives the generated HTML.

In practice, there is a limit:
with around 200–500 records in an HTML table, the browser UI starts to feel heavy.
This is not a Harbour limitation, but a result of:

HTML size

browser rendering
network transfer
That is why web applications usually use techniques such as:
paging (for example 100 records per page)
loading data incrementally

or calling the program again and continuing from the next record or offset
Best regards,
Otto

LOCAL aData := {
   { "John Smith",     "12 Oak Street",     "London" },
   { "Emily Johnson",  "45 Baker Street",   "Manchester" },
   { "Michael Brown",  "8 River Road",      "Oxford" },
   { "Sarah Wilson",   "221 King Avenue",   "Bristol" },
   { "David Taylor",   "19 Hill View",      "Leeds" },
   { "Laura Anderson", "77 Green Lane",     "York" },
   { "Robert Thomas",  "5 Station Street",  "Cambridge" },
   { "Anna Martin",    "30 Park Crescent",  "Bath" },
   { "James White",    "102 High Street",   "Nottingham" },
   { "Olivia Harris",  "16 Meadow Close",   "Reading" }
}

LOCAL cHtml := ""
LOCAL i

cHtml += "<table border='1' cellpadding='6' cellspacing='0'>" + CRLF
cHtml += "<thead>" + CRLF
cHtml += "<tr>" + CRLF
cHtml += "<th>Name</th>" + CRLF
cHtml += "<th>Street</th>" + CRLF
cHtml += "<th>City</th>" + CRLF
cHtml += "</tr>" + CRLF
cHtml += "</thead>" + CRLF
cHtml += "<tbody>" + CRLF

FOR i := 1 TO Len( aData )
   cHtml += "<tr>" + CRLF
   cHtml += "<td>" + aData[i][1] + "</td>" + CRLF
   cHtml += "<td>" + aData[i][2] + "</td>" + CRLF
   cHtml += "<td>" + aData[i][3] + "</td>" + CRLF
   cHtml += "</tr>" + CRLF
NEXT

cHtml += "</tbody>" + CRLF
cHtml += "</table>" + CRLF

System Error Execute general.html Error BASE/EG_ARG(1) 6101 Description Unknown or unregistered function symbol Operation TARRAYDATA

Otto...gracias por responder...

Solo queria saber si esta clase ya esta en mod_harbour... dado que hix 1.2 ya tiene soporte para sql...

La tecnologia web la entiendo perfecto... solo queria ver si puedo aprovechar el codigo fuente, que tengo para gestionar las respuestas de una base de datos o de un servidor de aplicaciones.. Lo que quiero es comparar lo que hago en la web ( angular + nodejs / jakarta ee ) usando localStore (js o TS ) / json, frente a TarrayData ( de hecho seria almacenarlo en un LocalStore)

Hello Russimicro, The error you see simply means that TArrayData is not available by default in mod_harbour / HIX. It is a FiveWin class, not part of the Harbour runtime or the web framework.

Conceptually your comparison is correct, but there is an important difference:

localStorage lives on the client (browser) and survives multiple requests

TArrayData lives on the server and only exists during one program execution

In a web environment the server is stateless: once the response is sent, the Harbour program ends and all in-memory data (arrays, TArrayData) is gone.

Using TArrayData as a temporary working structure to process SQL/DBF data and generate HTML is perfectly fine.

But it cannot replace localStorage, because localStorage is client-side and persistent.

If you want a persistent server-side state, you need something explicit: session, cache, database, file, or a long-running service. Best regards, Otto

Hi Russimicro,
Between the browser and Harbour you will always have JSON (or HTML).
Calling it a microservice or HIX does not change that — HIX is simply the Harbour-based implementation of that service layer.

On the browser side you can of course use asynchronous JavaScript techniques, like fetch, to load or store data in the background.
But even then:

every call is a new HTTP request
a new connection is created
data is exchanged as JSON or HTML
the server remains stateless per request

So even with async loading, nothing is shared implicitly between browser and server.

TArrayData can be used inside the Harbour/HIX program as a temporary working structure
(for example to process SQL or DBF results and generate HTML or JSON).
But anything sent to the browser must be serialized — the browser never sees Harbour objects.

If this is already clear to you, then we are fully aligned.
If you like, I can also show a very short fetch() example to illustrate this flow.

Best regards,
Otto

https://forums.fivetechsupport.com/viewtopic.php?p=283398#p283398

Buen dia.. Otto...

Si correcto, TarrayData es de fivewin... La pregunta está orientada a saber si las clases de fivewin que manejan datos como está o la misma mariaDb.. serán migradas, ante el apoyo que ya se ofrece HIX 1.2. para que la migración sea más directa en la parte de la lógica...

Ahora el uso de un objeto TarrayData, en toda la aplicación lo puedo lograr si lo almaceno en un localStore o una variable de Session.. y lo recupero y lo operaria con los métodos ya existentes de TarrayData---

Algo así podría ser :

function Main()

? "<script>" ? "let miArray = [1, 2, 3, 4];" ? "localStorage.setItem('miArray', JSON.stringify(miArray));" ? "</script>"

return nil

Nota : Incluso también uso sessionStore.. para datos que almacenar configuraciones propias de cada puesto de trabajo y no tener que leerlas en cada conexión del cliente... ( impresoras, etc)

Hello Russimicro, Yes, I understand what you are trying to do, and your reasoning makes sense.

First, an important clarification, because this is often misunderstood:

When you write something like this in Harbour:

? "<script>" ? "let miArray = [1, 2, 3, 4];" ? "localStorage.setItem('miArray', JSON.stringify(miArray));" ? "</script>"

no JavaScript is executed on the server.

Harbour (or HIX) does not execute JavaScript at all. It simply outputs plain text as part of the HTTP response.

What really happens is:

the server generates text (HTML + <script>)

the browser receives that text

the browser parses the HTML

the browser executes the JavaScript

From the server’s point of view, <script>...</script> is just a string.

Now to your main question about TArrayData and localStorage.

TArrayData is a FiveWin class. It exists only on the server, and only during one program execution.

localStorage / sessionStorage, on the other hand:

live in the browser

store only strings (usually JSON)

persist across page reloads

have no knowledge of Harbour or FiveWin objects

So while the comparison is understandable, they are not equivalent.

What you can do is this:

on the server:

read data from SQL / DBF

process it using arrays or TArrayData

generate HTML or JSON

send that HTML or JSON to the browser

on the client:

optionally store the JSON in localStorage or sessionStorage

use JavaScript to work with that data

What you cannot do is:

keep a TArrayData object alive across requests

store a FiveWin object in localStorage

call TArrayData methods from the browser

This is because the web environment is stateless:

every HTTP request is new

after the response is sent, the Harbour program ends

all in-memory objects (TArrayData, arrays, variables) are gone

Even if you use asynchronous JavaScript (fetch, AJAX, etc.):

each call is still a new request

data is exchanged as JSON or HTML

no implicit state is shared with the server

In short:

TArrayData is useful as an internal, temporary processing structure

JSON is the transport format between browser and server

localStorage is a client-side cache, not a server object

HIX provides the service layer, but it does not change these rules

Using localStorage for client-side configuration (printers, UI settings, workstation data) is perfectly fine and common. But it is not the same as keeping server-side objects alive.

Key takeaway:

the server generates text

the browser executes JavaScript

objects do not cross that boundary

If the goal is to reuse logic, the usual pattern is:

keep logic on the server

exchange data as JSON

rebuild the needed structures per request

That keeps the architecture predictable and avoids hidden state.

Server vs. Browser (very important)

First, an important clarification:

When you generate this in Harbour:

? "<script>" ? "let miArray = [1, 2, 3, 4];" ? "localStorage.setItem('miArray', JSON.stringify(miArray));" ? "</script>"

no JavaScript is executed on the server.

Harbour (or HIX) only outputs plain text. The server does not understand JavaScript and does not know localStorage.

What happens is:

the server generates text (HTML + <script>)

the browser receives the text

the browser executes the JavaScript

From the server’s point of view, <script>...</script> is just a string.

Part 2 – JSON embedded in HTML and localStorage (ONE WAY)

Yes, if the server embeds JSON data in the HTML and sends a <script> that processes it, the data will be stored in localStorage — but only in the browser.

Example flow:

server sends HTML containing JSON + <script>

browser parses the HTML

browser executes the script

data is written to localStorage

This is a ONE-WAY operation.

Important:

the server does not automatically get this data back

the server does not know what is in localStorage

the data exists only on the client side

If the server needs the data again, the browser must explicitly send it back (e.g. via fetch, POST, JSON).

Part 3 – Relation to TArrayData, HIX, and state

TArrayData is a FiveWin class:

it exists only on the server

only during one program execution

after the HTTP response is sent, it is gone

localStorage / sessionStorage:

live in the browser

store only strings (JSON)

persist across reloads

have no methods, only data

So while the comparison is understandable, they are not equivalent.

You can do this:

server (Harbour / HIX):

read SQL / DBF data

process it using arrays or TArrayData

generate HTML or JSON

browser:

execute JavaScript

store JSON in localStorage

send JSON back when needed

But you cannot:

keep a TArrayData object alive across requests

store a FiveWin object in localStorage

call TArrayData methods from the browser

Even with async techniques (fetch, AJAX):

every call is a new request

data transfer is always JSON or HTML

the server remains stateless

Key takeaway (one sentence)

Server → Browser is ONE WAY by default. JavaScript runs only in the browser. JSON must be sent back explicitly.

Best regards, Otto

Hello Russimicro, Hello,

there is one very common and valid use case where browser-side storage makes a lot of sense: field service / offline applications.

Example: a sales or service person wants to take a price list with them and work offline.

In this scenario, the goal is not to replace the server or the database, but to carry a local copy of the data while being offline.

A typical flow looks like this:

Online (office, hotel, WiFi)

the browser fetches JSON data from the server (for example a price list or product catalog)

the data is stored locally in the browser

Offline (on the road)

the application reads the data from browser storage

search, display, and selection work without any network connection

Back online

changes or selections are sent back to the server via JSON the server stores everything in SQL the server database remains the source of truth

For this use case, localStorage is usually not sufficient. It is small and synchronous.

The correct browser-side storage for this is IndexedDB:

works offline supports large datasets asynchronous (good performance) structured data (objects, keys, indexes) available in all modern browsers

Important distinction:

IndexedDB / localStorage → client-side storage → belongs to the device / browser → can be cleared or lost

SQL on the server → server-side storage → central, consistent, backed up → source of truth

The connection between both worlds is always JSON. Even in this offline scenario:

server sends JSON browser stores JSON browser sends JSON back when online

No browser storage replaces server-side persistence. It only provides an offline cache.

In short:

browser storage is for mobility and offline work server storage is for consistency and persistence JSON is the bridge between both

This pattern is well established and works independently of the backend technology (Harbour/HIX, Node.js, Jakarta EE, PHP, etc.).

Best regards, Otto

Otto... mi logica de desarrollo web siempre está enfocada en separar la capa cliente y la capa servidor ... frontend y backend

lo que pretendo solo para este caso, es reemplazar la aplicación local que uso en PC - WINDOWS (cliente pequeños) con un desarrollo rápido usando hix + MOD_HARBOUR + sql nativo(mariadb) o desde servicios API REST - WEBSOCKET.. ( mod_harbour o harbour o nodejs, ...)

aquí es donde entra TARRAYDATA( )... con esta clase tengo toda mi lógica para manejar la respuesta del server API REST o DB-SQL o tablas DBF .. que busco !!! cargar los datos en tarrayData y si requiero persistencia entre .prg o funciones ... llevarlo o subirlo o bajarlo con un localStore.

Pero si tengo que reescribir toda mi lógica de harbour a JS para el manejo del json de repuesta... prefiero seguir por el camino que ya conozco y estoy usando para clientes nuevos y 100% web empresariales... que es usar ANGULAR con JS O TS... para parte cliente - FRONTEND y nodejs o PY o JAKARTA EE para el BACKEND

Nota : Solo estoy explorando que tan rápido y que no requiera cambiar mucho de mi lógica ... podría ser en migrar a hix como servidor + (html + javaScript) + mod_habour + mariadb / dbf de hecho, seria mantener hasta el mismo diseño de pantallas, usando antiGravity,,,

Pregunto a Antonio o Carles... es posible migrar la clase TARRAYDATA... a mod_harbour ?

Hello Russimicro,

In the end, regardless of which backend is chosen (HIX / mod_harbour, Node.js, Jakarta EE, Python, …), the frontend is always HTML + JavaScript.

Personally, if I had to build this today, I would consider removing Angular from the equation and implement the UI in plain HTML + JavaScript, without heavy third-party frameworks.

Not because Angular is “bad”, but because: the frontend becomes backend-agnostic the same UI can talk to HIX or Node.js without changes less tooling, less build chain, less coupling easier debugging and long-term maintenance

Angular is no longer a default choice. It is one option among many, and its usefulness depends on context — especially as AI-driven tooling can be disruptive to established frontend workflows and changes how quickly UI code can be created, refactored, and maintained.

With modern browsers, fetch/async, modules, and AI assistance, a clean HTML + JavaScript frontend is often sufficient and more flexible for new projects.

That also keeps the focus on what really matters:

clear APIs (JSON) clean server logic no tight coupling between frontend and backend technology

If there are no confidentiality issues, screenshots of the existing software could be very helpful. Seeing the actual UI often makes it much easier to discuss concepts, data flow, and migration paths in a concrete and constructive way.

That would allow us to talk about architecture and ideas, instead of debating tools in the abstract.

Best regards, Otto

To your question: You can process data the same way as before. But you cannot expect TArrayData to live in the web environment the same way it does in a desktop application.

Russimicro,

russimicro wrote:

Nota : Solo estoy explorando que tan rápido y que no requiera cambiar mucho de mi lógica ... podría ser en migrar a hix como servidor + (html + javaScript) + mod_habour + mariadb / dbf
de hecho, seria mantener hasta el mismo diseño de pantallas, usando antiGravity,,,

Pregunto a Antonio o Carles... es posible migrar la clase TARRAYDATA... a mod_harbour ?

HIX no tiene nada que ver con el mod, los dos tienen como objetivo ser un servidor web. Si usas mod, tienes todos los fuentes y podrias enlazar la clase TArraydata, yo no la conozco. Si usas HIX puedes intentar con el loader cargar la clase o desde cualquier prg hacer un #include

C.