I was able to change the code and get it working to edit the database 
by adding single quotes around the offending item âŠ. what will that do to a integer value ?
If row IsA RowSet Then
RowSet(row).Close 'unlock the row
'Now reload the row in case the user wants to edit it again
CurrentRow = Connection.SelectSQL("SELECT * FROM " + Table + " WHERE " + " ' PrimaryKeyColumn ' "+ " = " +" ' PrimaryKeyValue ' ")
End If
Use the code button
thanks
From the DBKit-Doku this should be fixed. @Geoff_Perlman
this code cannot work for string or integer primary key !
PrimaryKeyColumn must not be between single quotes
The last code, besides the basic bug, showed absence of SQL Injection protection, like SQL parametrization. I hope they have fixed cases where names and values may contain injected âtrapsâ.
Yes, I am a bit surprised that Xojo went through all the trouble of supporting the parametrized syntax and then Geoff not using it. Some DBâs use $1,$2, otherâs ? as the paceholder but that is something the DBKit should handle properly. It would also have handled quoting and escaping issues. Maybe the newer version handles all of this.
(post deleted by author)
Looks like some code was updated (LoadSelectedRowContinue) but not this one (SaveRow):
Xojo2026r1.2, dbkit loaded b19 from examples.
All I see are four lines that glaringly scream not to use DBKit.
Personally, I would not recommend DBKit as I think it has many deficiencies. Too many to go into here.
Way back when my company did Xojo consulting we created ActiveRecord and ARGen to make it easier to create boilerplate Xojo code and UI from a given database schema. Used it in dozens of really big projects and it was such a time saver.
Essentially if you had a table, or view (important!) it would create a class. So a users table would have a corresponding users class and the properties on the class would map to all the columns in the table. It also had corresponding Load/Save/Delete methods that you could modify to suit your needs. And, if you had set the relations up properly in ARGen it would create any properties and methods related to it. For example, if you had a permissions table that tied into the users table it would just automagically create the right stuff in the Users class AND the Permissions class. It would auto populate some of the code too so in the Load method youâd get stuff like this:
FirstName.Text = me.FirstName
LastName.Text = me.LastName
And so on. Save would have similar attributes.
Each class would have Before/After Create, Update, Delete events where you could do whatever you needed to do for related data. The Before events allowed you to cancel the process and provide whatever feedback you wanted to give the user. This was also a good place to check Record Locking (i.e. the record has been updated since youâve last read it!).
Views would automatically resolve into their constituent table classes.
As far as UI goes it would take some guesses based on the column type on what type of control it would take (numeric and text columns would assume TextField, booleans would take a checkbox, etc) but you could change it in ARGen to say make it a ComboBox or something else. One click later youâd have the shell of an application with all the needed classes, modules, windows, dialogs, containers, etc.
Was their work to do afterwards? Of course because I, as the developer, wanted total control of how controls loaded and saved data. But it saved countless hours. Was it perfect? Nope, but it worked for 95% of our clients needs and it never stopped you from rolling your own implementations.
Since my time itâs been sold, open sourced, and is available at GitHub - undtec/argen: Xojo ActiveRecord Generator · GitHub. I do not know if itâs fully API 2 compliant or if itâs up to date with the new Desktop style controls. But since itâs open source you could update it and help the community.
This is fixed in the next release of DBKit.
DBKit is all about the UI, not turning rows into objects. The current release is v1. The v2 release adds a TON more functionality but again itâs all about the UI.
Yes, itâs all about the goalâŠ
Using a computer allow people to make a better job for not more time than it takes to make a âstandardâ goal (what we was doing without a computer).
Donât you see the benefit allowing all of us doing a better job ?
Maybe, but it never comes.
I do not care anymore since the day I was retired (and I lost hope so many years ago).
Thatâs A way of approaching it. Youâre trying for a 4D/FileMaker simplified approach and we felt that was not the best way of doing it. We thought about it found just too many edge cases that made it more challenging to implement and perfect.
We decided that we wanted ultimate control of the data which, to us, was more important than the UI. This included wanting control over how and what the controls displayed. We never had to subclass any controls to get it to work with ActiveRecord. We also felt that the objects should contain the business logic and not the UI and AR made that very easy as well (IIRC we had a validate event that made it easy to do).
AR was not perfect but it was relatively easy to pickup and use. And adding record locking was dirt simple which I pointed out that DBKit was lacking way back when it was first released. While many Xojo users wonât care because theyâre using a single user SQLite database as soon as you get into multi-user DB server applications that can (and should) be an important aspect to any application.
Again, we were using AR in some high powered Xojo desktop and web applications that took many months to even get to beta stage and it saved us much time (1-click to create an entire project with classes and UI with a some of pre-wired). And using it caused multiple developers to use similar code so it was easy for others to debug when an issue did come up.
There are plenty of people using DBKit successfully as well. ActiveRecord and DBKit are solving different problems.
