Should I accept what is happening?

[Das Goravani]

I captured $sqltext as Rudolph suggested and it looks like this:

UPDATE fcEvents SET evchartnum=?001,evetname=?002,evdate=?003,evtime=?004,evcity=?005,evstate=?006,evcountry=?007,evnote=?008,evdateonly=?009,evroughdate=?010,evrsn=?011 WHERE evrsn = ?012

Is it healthy that it has question marks and numbers where the values go?

The above comes from the statement object just after executing an $update command, ORM command, so the above gets NO ERROR REPORTED keep that in mind.. nothing at all in session object $errortext except the phrase “no error has been reported”


Now the following is the $sqltext from the SQL statement that DOES work 


UPDATE fcEvents SET evchartnum=?001,evetname=?002,evdate=?003,evtime=?004,evcity=?005,evstate=?006,evcountry=?007,evnote=?008,evdateonly=?009,evroughdate=?010,evrsn=?011 WHERE evrsn = ?012


The code that generated the above is what works, to actually save data, is straight from the manual, and looks like this:


Do tstaobj.$execdirect(con('UPDATE fcEvents ',tsessobj.$updatenames(tvfcEventsrow),' WHERE evrsn = @[tvfcEventsrow.evrsn]')) Returns #F

The above two SQL statements generated by Omnis are identical.. but one doesn’t work and one does, the one from ORM, first example, doesn’t work, and the one from a SQL-like statement, call it omnis-SQL version 2.0 above ORM, that works

So it’s NOT the SQL that is being generated that is working or not working, the SQL is identical in these two cases, but ORM does not update the data on disk, the 2nd approach does

This tells us that it’s not just the SQL that causes data to go to disk or not.. it is like, it is exactly like, sandboxing is turned on, I am saying the right command, it is generating the right SQL.. but the task is not happening.. the data doesn’t go to disk as if to say ORM is saying “I’m only kidding” about writing data to disk, sandboxing

The second approach, same SQL generated, WRITES data to disk

It is as if I have invoked sandbox mode on ORM in my copy of Omnis with no way of knowing that or setting it back the other way.. a secret back door that I hit by accident.. and turned on “Kidding” mode.. “do the whole charade but don’t issue the write command”

I DONT KNOW I’m only trying to figure this out to see if ORM $update is useable at all.. so far the conclusion is 5 files tested and failed, no success $updating with ORM.. makes me think it’s time to write that second level approach generic update method for myself.. because it will be too many individualized statements otherwise.. there’s 89 file formats in this project though not all of them write data to disk many are static look up files I created and some are MOFFs for variables from old approach days

The problem with those longer commands is that they so far are singular to one table.. I would have to do a bunch of work to make it generic … a table of my tables with the primary index field stored.. because that’s needed in the command.. I already have the table name which establishes my row name, my method, same names used throughout makes it easier

I mean by that that my old files, are now my tables exactly, and my rows are formed with the table name and otherwise static letters

Ie

fcEvents     the original file class, still being used as I use CRB
fcEvents     name of the table made of same fields, columns as file class, same names
tvfcEventsrow     my row name for this file/table
tvfcEventsold      my old row for this table
scEvents            The schema for this table, same names as file and table
tcEvents            The table class for this table

So it’s easy to make up all things if you just have the name of the file you are working on which is the name of the table, so it just depends on how you look at it

This approach makes doing generic code a lot easier

And I’m sure you all know this but just in case

And to be clear about what I am doing

I did not make my primary keys for each table have the same naming logic so I have to manually curate a list of tables and primary keys for my new generic update method, darn it

Once I handle this update method, my only lagging problem will be this SQLite Bloat.. that is to say, my SQLite database is doing this thing where sometimes it grows a LOT when no data is being added, only some records got updated, and hundreds of MB’s get added to the DB.. sometimes it has grown from it’s real size at 350 MB to 11 GB over the period of a week of just editing a few records, nothing at all, and it says when I run the SQLite3_analyzer tool on it that there are all these ghost records in my cons file.. which gets edited.. it’s a table that gets updated a bit more than others.. it’s a large record with a lot of fields but it’s not hundreds of MB no.. many ghost records get added to that table poofing it up real big.. huge ghost records get inserted.. you cannot pull them up by the SQL Browser.. it shows only the one legit cons record that is in there… SQLite3_analyzer reports on the presence of these other records… 

So I have a DB problem with ghost records of huge size bloating up my DB when I do simple edits, I think.. when I went to test it to nail it down it wouldn’t grow of course.. when you chase it it disappears.. when you’re not looking it does it’s thing.. that’s what’s happening to me.. forget about it for awhile and it grows, try to hunt it down and it won’t grow

But so far it seems to come from either testing remote forms, oddly, or from editing records.. as I’m not adding any

The difference in record count between Omnis and SQLite3_Analyzer is real and true and disturbing

I have both of these problems put before US Support and am awaiting response. 

SQLite has “nothing” about log files anywhere.. the only thing they have is instructions for the likes of Omnis who is integrating functionality into their app … sqlite gives the developer ways of making log files.. I dont know if Omnis did anything with SQLites error reporting facilities.. I can’t see anything obvious.. can’t find an error log file.. the SQL looks good, no error is reported.. something else is up