I think I have properly followed all the instructions on file placement and changes to the redirection file.
I compiled the StringTheory DLL separately first, just in case (it is the last item in the DriverKit.sln), and I never made it to the end.
Second problem was that as soon as it hit the construction of the TypeDescriptor, e.g. line 410 in Dos2Driver.clw, it complained about not knowing any of the OpCode:xxx equates. I “solved” this by moving the entire OpCodes region in driver.inc up right after the Includes region. Shouldn’t make any difference, but it did – maybe there is something weird later in the Driver.inc file that is throwing things off?. So now I get down to line 610 in the dos2driver, which is the first driver the solution tries to compile), and it craps out at: DriverObject &DriverFileDos2Class,auto
Illegal data type: DriverFileDos2Class. That class is declared in Dos2DriverClass.Inc, which is included at the top of the file – no complaint about not finding it. Any suggestions on what to do?
Just download original code again and open each clw and inc file from “source” subdir using some text editor (I prefer flo's freeware - Notepad2)
and change line endings from Unix to Windows, save each file and compile the driver again.
That worked perfectly. Just had to move a MEMBER() up to the top of the file, same as with the PROGRAM, and it all compiled. Now comes the fun part – seeing if the SQLite driver solves the problems I had with the shipping driver.
I also found that the GitHub DriverKit .Zip download had the wrong line endings (just Chr(10) for Linux).
One way to get them correct is to install GitHub Desktop and in it configure your Line Endings to be 13,10. Then clone his Repo. This has many other features and is free.
@Bruce should edit his .gitattributes file to fix this so the Zip has CR,LF for Windows systems.
# Auto detect text files and perform LF normalization
* text=auto
Below are the settings I have in my .GitAttributes. I got them from Randy’s Devuna Repo and added a few lines:
# https://help.github.com/articles/dealing-with-line-endings
# Set the default behavior, in case people don't have core.autocrlf set.
* text eol=crlf
# Explicitly declare text files you want to always be normalized and converted
# to native line endings on checkout.
*.clw text
*.equ text
*.inc text
*.int text
*.cwproj text
*.pr text
*.red text
*.sln text
*.trn text
# Declare files that will always have CRLF line endings on checkout.
*.sln text eol=crlf
# Denote all files that are truly binary and should not be modified.
*.app binary
*.bmp binary
*.chm binary
*.dct binary
*.dll binary
*.exe binary
*.gif binary
*.hlp binary
*.ico binary
*.jpg binary
*.lib binary
*.png binary
*.zip binary
*.docx binary
*.pdf binary
# Declare languuage association
*.clw linguist-language=Clarion
*.equ linguist-language=Clarion
*.inc linguist-language=Clarion
*.int linguist-language=Clarion
*.tpl linguist-language=Clarion
*.tpw linguist-language=Clarion
*.txa linguist-language=Clarion
*.txd linguist-language=Clarion
*.apv linguist-language=Clarion
*.dcv linguist-language=Clarion
I’d like that. Git is from the Linux world so wants to keep files with that EOL Chr(10). When I search for how to retain my 13,10 EOL the same it offers this setting:
To disable all automatic line ending conversions globally:
git config --global core.autocrlf false
I think that’s only on my Repo. Googling “how does core.autocrlf false affect other users that fork” returns A LOT in the AI Overview.
To force for everyone else I think the only way is with the .GitAttributes file in the Repo that I posted above.
If anyone is interested in how the SQLite OBD Project files are “arranged” I ran it thru my Scan INC which builds a Tree of the files either Included or Link(). This is not exactly an Object tree, but kind of is. Its different in seeing files that are not Classes. If an INC file declares multiple classes you see each line e.g. DriverClass.CLW.
Below you see the Root file of the Project is SQList2Driver.clw and it includes the Class SQList2DriverClass.inc where the majority of the Object Based Driver code exists.
From my really quick look at the classes my understanding is something like this. For a Clarion GET() say, you have to go from there to asking the server for the data and getting the data into the file buffer.
The way it looks like this is broken up is that the CWDriver files map the Clarion calls to methods in the DriverFileClass and the DriverFileSQLClass. For SQL the class would handle constructing the statement to send to the backend (select <all_columns> from whatever_table where KeyValue = <key_value>.
The other classes sit on top of that and actually handle communication with the server (or file system), which includes things like binding the “fields” in the buffer to the columns returned in the result set, dealing with conversions (for dates and times etc), and actually sending the constructed query with whatever parameters it needs to the server. In that top layer you might also deal with server-specific SQL variants (like MSSQL TOP vs other SQLs LIMIT), maybe overriding some of the methods in the base class. It’s only in that top layer you deal with server-specific stuff, like the SQLite2DriverClass.clw is the place where all the methods in the SQLite API are documented in the MAP.
Hopefully that’s not too far off. I still know nothing about some important questions, like where would the decision to do a client-side join rather than sending a complicated query to the server, be made? But I think you’d be able to discover when and why it happens using these drivers, whereas with the shipping drivers you are just looking at a black box. I would guess the decision is made in the top layer (which has asked the server about its capabilities), but then that has implications for the query (set of queries) that is/are actually produced to retrieve the data, which I think is done in the parent class (DriverFileSQLClass).
You’re on the right track, but off on some details.
Cwdriver declares new functions, not existing ones. This routes those functions to the respective object for the File or View.
Existing functions are handled by the compiler. These flow through a Pipe function, and then to the Pipe function in the attached object.
A Clarion File (or View) is a FCB (or VCB) which contains a pointer to the object. So it goes from Driver Pipe to Object Pipe. Theres some technical stuff that makes the parameters work.
Using prop:object you can get a pointer yo the object, assign that to a reference and access the object directly. You will likely never do that, because the command and property interface supplies most everything. But technically you can.
The new drivers do not do client-side views at all. Frankly i consider that feature to be a bug in the SQL context. Thats discussed in the docs.
If you want to understand the drivers, i recommend starting with the docs. Read them through. There are a lot of details about the drivers which are incorrectly understood and the docs help set a baseline for that.
The classes of course contain the source which describes how everything works. Some parts are very complex. Some are very simple.
