I use a fairly normal Listbox (the replacement WAs going to have varying rowheights, but it was way too much work in relation to this project)… so basically where I populate the listbox I have code like this
' s is a string with what should go into the cell
If ReplaceLineEndings(Trim(s),"X")<>Trim(s) Then
lb.CellHelpTag(lb.LastIndex,i)=s
x=InStr(s,EndOfLine)
s=Left(s,x-1)+"..."
End Ifnow if there was a way to control (easily) the font/size in a CellHelpTag
I have now released version 2.10.5. This has a significant number of additional improvements and, I think, is probably ready for real usage.
Download a copy here:
SQLite Control
Any comments/suggestions etc. please let me know.
Simon.
How does one set a value to NULL in the “Table Data” screen?
I think you are over-enforcing the datatypes… where your app is more strict than SQLite itself is, and that might cause problems if a user wishes to take advantage of that flexbility
[quote=327293:@Dave S]How does one set a value to NULL in the “Table Data” screen?
I think you are over-enforcing the datatypes… where your app is more strict than SQLite itself is, and that might cause problems if a user wishes to take advantage of that flexbility[/quote]
In the Table Data tab you cannot enforce anything other than the specified data type. If you want to override that (which is the way that I chose to design the app) then just go to the SQL tab and write the insert statement directly.
My basic philosophy is that if a field is defined as an integer then it should be an integer (as an example). If you really want something different then just hand write the insert statement. You will also see that for any field that is defined as NOT NULL (other than primary key) the add row plus button on Table Data will not work either. This was by design.
As you know, Dave, there are things that irk some users more than others and features that not many users will use! I have taken the basic philosophy that a DB Manager should enforce the designed structure even if the underlying database will allow anything (basically as SQLite does). In my opinion (and, I stress, my opinion!) this is what a DB Manager should do. I have supplied tools that allow the user to override and modify a database, even changing its underlining structure. So, if a user has now found that he wants to use a previously defined field as a string rather than its original definition as an integer then he can change the field type. He can then use the Table Data tab to add/remove/change that original field to a string etc.
I think it is worth pointing out that you are producing a commercial application and, I guess, that should conform more to the SQLite ‘standards’ and allow anything in anything. That can (and probably will) cause you some grief in the long run. My app is a free version so I can choose what ‘standards’ to enforce! I really want to stress that I am not criticising, just stating my design criteria.
This has been a fun project for me and I have picked up some really useful tips from you in this forum, especially with the questions that you ask. These have pushed me down some roads that were really difficult but the advantage was that they made me really think about what I wanted and should incorporate.
Thanks again for the comments and I hope that I answered your basic question!
Simon.
Simon, I am in no way telling you how to or not to write you application… I am now, as before just trying to point out some things that most developers might expect from an app that deals with SQLite databases… And by no means mean to diminish the “fun” or educational experience that this is for you. And I have seen your application grow considerably since the forum topic began.
Tadpole (my app) is still evolving… and I hope to have a beta version in a week or so…
[quote=327343:@Dave S]Simon, I am in no way telling you how to or not to write you application… I am now, as before just trying to point out some things that most developers might expect from an app that deals with SQLite databases… And by no means mean to diminish the “fun” or educational experience that this is for you. And I have seen your application grow considerably since the forum topic began.
Tadpole (my app) is still evolving… and I hope to have a beta version in a week or so…[/quote]
I didn’t think you were telling me how to create my app, I was attempting to let you know my philosophy (obviously not very well!).
I really do appreciate your comments and suggestions. Indeed, they have significantly helped me to improve the app over the last weeks. In addition to improving the actual app your comments/suggestions have made me focus on what I really wanted - hence my explanation of my philosophy.
In addition I am mindful of your app being produced and on a commercial basis. I don’t want to impact any of your sales so I will probably stick with my own philosophy, even though it digresses from the basic SQLite philosophy. I do believe that there is a market out there and I will not be attempting to pursue that as I really don’t have the time for marketing. I just like the challenge of creating software, not all of the marketing efforts required to make it a big seller! That, my friend, I will leave to you!
Simon.
SQLite locking concept comes when we access database from multiple threads. What things should we keep in our mind while designing the database in android, lets see.
firstly we create a helper class which extends SQLiteHelper class:
public class DatabaseHelper extends SQLiteOpenHelper { ... }Now lets we have multiple thread which are writing the data in database like this.
[code]//thread-1
DatabaseHelper helper = new DatabaseHelper(getApplicationContext());
SQLiteDatabase database = helper.getWritableDatabase();
database.insert(…);
database.close();
//thread-2
DatabaseHelper helper = new DatabaseHelper(getApplicationContext());
SQLiteDatabase database = helper.getWritableDatabase();
database.insert(…);
database.close();[/code]
Now, when we run this code, we may get following exception:
android.database.sqlite.SQLiteDatabaseLockedException: database is locked (code 5)
why it actually occurred?
From SQLite FAQ:
Multiple processes can have the same database open at the same time.
But only one process can be making changes to the database at any moment in time.
It means, In multithreading environment, multiple thread can read database but single thread can write to database. i.e. in our case, we are creating many helper instance and one helper instance is responsible for creating one database connection and if we make multiple helper instance then multiple database connection we will have.
What does this have to do with either this topic or Xojo in general… no Android here
Yet 