Comments about "What's cooking"

[ic2]

Hello Robert,

It should be solved now.
/quote]

Indeed. And without deinstalling the updates!.

Dick

[robert]

Dick,

It should be solved now.

Indeed. And without deinstalling the updates!.

No I did not uninstall anything. But I had to change a (new) configuration option for which the default value was not working as expected on our website with our unique combination of components and modules.
And like Chris I was not seeing this because after opening the website I also usually use the scroll wheel to scroll the page to see if there is something new.

Robert

[jpmoschi]

Good afternoon Guys
I would like to express my opinion regarding the proposed roadmap, starting by saying that my view is skewed from the point of view of a FoxPro user who works with this tool since the 80s.
First, a brief introduction: the logical path followed by a FoxPro multi-user application developer was to migrate to Client Server in the 1990s with the understanding that the table management strategy on a file server would not be scaleble. I would love to know how many of the Friends of XSharp Group maintain multi-user systems on File Server today. Surely there must be a lot to justify the FoxPro COM solution but it is not a solution for me.

Now, the proposed solution of using a Local RDD to support SQL involves first taking the data from the RDBMs (x eg MS SQL Server) and entering it into the local RDD and then executing code with Sql commands and non Sql command mixed. Ex:
1st. select * from T
2nd. select * from tj1
3rd. select top N * from T ... join tj1 on ... order by ...
It should be noted that the previous example is a simplification that deliberately excludes the intermediate FoxPro code lines that justify the solution

Thinking that the execution may not be fast enough if any of the involved tables grows, I am seeking a local solution equivalent to "embedded sql" using the data manipulation tools availables in XSharp. The idea has the advantage of not being separated from the current execution context of the program. Understanding that the execution context are the private DataSessions, parameters, variables, objects and vectors declared in the normal flow of program execution.

The following is the header of the proposed function and it is oriented to solve 95% of the queries used in my applications.

Code: Select all

 public method SQLSelect (paFieldsInSelect: = NIL as Array, pInToAlias ​​as Usual, pFrom: = NIL as Array, pJoin: = NIL as Array, pWhere: = null as CodeBlock, pArrayOrder: = NIL as Array, pdistinct: = false as logic, pTop: = false as usual) as logic

I ask you guys, is it not possible to think of a smaller solution like the one I express? I did some tests and the only bottleneck detected is the performance of DBCreateOrder and some errors in bulk operations reported in FoxPro forum (DbBulk.prg)

best regards
Juan