xsharp.eu

I suppose these are not working yet? USED(), DELETED() and INSERT INTO? I tried them out in code and they are not recognized. I think I read that INSERT INTO is not working. APPEND BLANK and REPLACE work well.

USING System
USING System.Collections.Generic
USING System.Linq
USING System.Text

#command SET DEFAULT TO <*path*> => SetDefault(<(path)>)

FUNCTION Start() AS VOID STRICT
LOCAL i AS INT
SET DEFAULT TO C:addrdata
SELECT 0
IF !USED("names")
USE names Index LastName
SELECT NAMES
* INSERT INTO does not work.
*INSERT INTO Names (LastName, FirstName) Values ('Champenois', 'Sean')
*APPEND BLANK
*REPLACE LastName WITH 'Champenois', FirstName WITH 'Sean'
SCAN for LastName = "Champenois" AND !DELETED()
? LastName, FirstName
ENDSCAN
WAIT
SELECT Names
USE
ELSE
? "The table, NAMES, is in use by another program."
ENDIF
RETURN

Hi Cecil,

when you look at the latest Used() and Deleted() Github sources you´ll see that the next release will contain the overloads: https://github.com/X-Sharp/XSharpPublic ... s.prg#L383

For the moment simply add both funcs to your sources and you can already do something like:
!! But don´t forget to remove both funcs from your sources as soon the next release is published !!

regards
Karl-Heinz

Cecil,
The function overloads that take an alias or workarea number will be added in the next build.
You can already see that code in Githib:
https://github.com/X-Sharp/XSharpPublic ... s.prg#L383

Robert

I suppose these are not working yet? USED(), DELETED() and INSERT INTO?

Cecil - Used() and Deleted() are VFP functions, and it sounds like those are easy, if not already done, ready for next release.

However, INSERT INTO is a different beast that X# Team will have to tackle. It's not quite as easy, if I had guess.

Matt,

Yes you are right. INSERT TO belongs to the "embedded SQL" commands.
We will implement these but this requires some work.

Robert

Robert - what is your priority between the "embedded SQL" commands, and the SqlExec() stack?

I bet SqlExec() is an easier task, but I think the "embedded SQL" commands are an important piece to demonstrate to VFP community to show X# is ready for serious consideration.

I know you mentioned using VFPOLEDB to handle embedded SQL, but one thing my little brain sees as an issue with that is that it seems like VFPOLEDB expects that the query will be run against all DISK-based DBFs, but in real apps we also need to execute embedded SQL commands against existing local cursors that are not on disk.

For instance, I often run SqlExec() to pull over a few separate cursors from Sql Server into VFP, then I run embedded SQL commands on the cursors to do JOINs, UNIONS, UPDATEs, INSERTs, etc on those local cursors to present data to user in reports, grids, etc.

Can you see getting VFPOLEDB to work with local cursors?

Matt,

VFPOLEDB was an idea, nothing more.We now realize that VFP also uses SQL against open cursors and that won't work.
We realize how important these queries are, so we will work on them, you can be assured of that.
I don't want to make promises here about priorities. We are doing some research into this at this moment. Based on the results of this research we will make the decision about priorities.

And yes we know what you want:

https://www.youtube.com/watch?v=Odkv4aE3pTI

Robert

Matt,
have not thought this through totally, but perhaps a quick way to get Sql select into xsharp might be to implement parts of cursor adapter.
This should be easier to map into Dotnet data structures and eliminates treating SQL as source - it is in the string property.
That way FPW2.6 level at least could be reached without adding oodles of responsibilities to the compiler, but delegating to existing Dotnet objects already sporting such capability.
Must think about it some more, but ADO.net should be up to provide executing a SQL string on both SQL backend and local tables.
Just a hunch...
thomas

robert wrote: VFPOLEDB was an idea, nothing more.We now realize that VFP also uses SQL against open cursors and that won't work.
We realize how important these queries are, so we will work on them, you can be assured of that.
I don't want to make promises here about priorities. We are doing some research into this at this moment. Based on the results of this research we will make the decision about priorities.

Robert,

I know you think mostly about cursors to be implemented via ADO.Net Datatable or something similar - which by being "in memory" is fast. For me the local cursor being on disk is a nice cache of the remote data store, even if not as fast as memory, although SSD helped a lot in the last years. Getting rid of the LAN or internet hop is more important than HANA-like analysis. Small, often accessed tables will be already OS-cached, so hopefully a bit faster than pure disc based stuff.

Piping into a local dbf from a firehose reader from ADO.Net should be doable, from then on data access to local dbf via SQL could follow via ADO.Net based data objects. Perhaps a ADO.net Commandobject containing the previous "inline" SQL is an alternative good enough to consider. If a memory based cursor can be added to be handled via same or similar code, all the better. Having identical method/code to interact with remote/local/cursor data IMO is more important than forcing the cursor data into RAM (which might again be swapped out to disc...)

And yes we know what you want:

Well, I sincerely hope the answer of xSharp dev team will be along the lines of
https://www.youtube.com/watch?v=onJQ1dpsAF8
regards

thomas

Thomas,

LOL.

Fasten your seatbelts. Be prepared to be rocked !

Robert