Repository navigation
Edit Table Definition dialog box - remember size and position #2689
Description
Describe the new feature
When I right click on a table and select "Modify Table" the "Edit Table Definition dialog box" appears.
The default size is almost always too small so it must be resized every time.
The feature I would like to see added is that it remembers the last height, width and location I used, was "Advanced" selected, position of the splitter bar etc.
Additional info
Using DB Browser for SQLite Version 3.12.1
Built for i386-little_endian-ilp32, running on x86_64
Qt Version 5.12.8
SQLCipher Version 4.4.0 community (based on SQLite 3.31.0).
on a 4k 17" laptop
Do you have a screenshot? Please add screenshots to help explain your idea.
Activity
chrisjlocke commentedon May 4, 2021
Aah, interesting you're on a high DPI monitor. This dialog seems awfully squashed on that resolution. The scrollbars seem quite thick and interesting that the button glyphs are quite tiny too.
I looked in the registry and couldn't see other dialogs that remember the size/position, but I think the main screen does.
As an aside, I note you've got the date as a 'dateTime' field. There isn't such a thing in sqlite.
chrisjlocke commentedon May 4, 2021
With regard to the small icons, can you tickle your environment variables?
See this comment:
#2305 (comment)
Obviously your own personal preferences, but you might be able to knock down the application font-size down one size. You should be able to do this from the 'Preferences' dialog.
fatscally commentedon May 4, 2021
My Display Scale settings are set to 200%, this usually zooms the text ok but often forgets the glyphs.
I was going to put this down as a bug elsewhere but yeah the icons are not scaling up. Microsoft also has this issue in some of their apps. And setting the location of controls in Visual Studio can be a bit mad, the X,Y is huge and when the app runs the scaling kicks in and things go mad but that's another story.
fatscally commentedon May 4, 2021
This did nothing noticeable.
chrisjlocke commentedon May 4, 2021
Bah, pants. Well, thanks for trying. It was a good attempt! 😉
Sounds an interesting project. Good luck with it! Day job or hobby?
fatscally commentedon May 4, 2021
It was a project I created for a Flying School in 2004. Worked really well. The girls simply said "It's too complicated". I was inexperienced and quickly disheartened and shelved it without another word. Much later I realised that I just installed it and left them to it, I should have said "I'll be up in an hour and I'll show you how to use it."
It has haunted me for years. I decided to un-shelve it and bring it back to life. I went back to the flying school to see if they'd use it and they adopted a system in 2018. I HAD A 14 YEAR HEAD START AND BLEW IT. That was a mental blow.
The guys gave me some leads of other small schools to try. The first one I met, despite having a paid system in place, agreed to work with mine to make it comprehensive to their bespoke needs. So I have a customer!!! Yay!!
The code behind is shockingly poor and out of date to todays standards. There are near 100% calls to the db from every sub procedure, so changing the db from MS-Access to Sqlite is arduous. Why change it?... coz .Net Core doesn't like Access without hacks.
Will be needing a UI guy to re-style it. Ultimately intend to re-write it in C# MVVM .Net Core. Dapper SQLite
Midnight and I'm still coding.... You know I'm enjoying it :))
chrisjlocke commentedon May 5, 2021
Yay! Sounds like my kind of thing. Well, apart from the MVVM.... and C# .... lol. I'm still stuck at VB.Net, but hey - it all compiles to the same thing in the end! 😉
Bear in mind that SQLite isn't multi-user. I've used it on a network before with no major issues, but writes were infrequent - only occasional record updates. If something does major writes (a long input) then it can lock everyone out. Also technically, as record locks aren't a thing, there is 'potential' for database corruption, so take backups often.
Getting at least one customer is a great start! When you meet customer #2, them knowing they're not #1 is a big bonus. Also once you get #2, you can start a customer meet-up forum! Haha!
My first (well, second technically) programming job was for a company that had developed their ERP system to run on a couple of Access databases, driven by VB6. We got in .Net, but I didn't bite to learn it and use it, and at a yearly personal development review, he stated he was disappointed no one in our team had used it after about two years. Like you, I'm kicking myself now and it haunts me, and wish I'd picked up C#. It's not a huge transition from VB to C#, but enough to make me keep going back to VB when I have a project to do. Even Dapper looks intriguing. I've coded my own ORM-ish framework, and looking at a Dapper example or two, my framework does more hand-holding... think I've over-engineered that! haha!
Good luck with the project! Keep in touch, as interested to know how you get on.
fatscally commentedon May 5, 2021
These tips are good to know. I'll obviously getting into Sqlite on a serious level now with this app. The first rendition will be one or two users only and on mobiles thereafter.
Industry forced me over from VB6 to VB.net to C#. This is a shock to the system going back. VB.net feels clunky. Although everything can be achieved in VB.net , C# is slick by comparison and I luv it nowadays. I recommend you bare the climb over the learning hump.
Dapper is wildly touted. I tried it out on this app with Sqlite and it is luv at first sight. Tiny code and furiously fast.
Doesn't have the labour and setup requirements of Entity Framework. Highly recommended on small to medium apps.
fatscally commentedon May 5, 2021
Who owns SqliteBrowser?
chrisjlocke commentedon May 5, 2021
Its open-source, so 'you' own it! 😉
Going off-topic of your issue, but hope you don't mind. How do you envisage this working? Will there be a central SQLite database, or is it a 'it can run locally' app? Linked to DB4S is dbhub.io which hosts SQLite databases. Once this gets developed a bit more, it'll be useful for these sorts of projects.
I notice you still have to throw it SQL statements, tables, and field names. In my world (!), each table is a class, so to select all aircraft, I'd simply create a reference to the class...
dim cAircraft as new clsAircraftThen that class can give me the records.
etc. Or to insert an aircraft:
dim newId=cAircraft.insert("YA675","Some thingy")So while coding, I don't need to know any field names, as auto-correct (or Intellisense) handles that. The only bug-bear is keep rebuilding the class if the database table changes (as the inserts, edit and populate functions need updating too) but I've a program to build that too from a table schema.
fatscally commentedon May 5, 2021
My initial drive was to just keep on using the MS-Access db and add the features the flight school requested. I hit a brick wall when .Net Core didn't want to play with MS-Access. Now I'm left with `15+ year old code that has no central connection point to the db and making straight calls to Access. Objective Numero Uno is to port everything VB.Net to Sqlite even if it still ends up looking like a dog's dinner. Just get it working! This is safe in the knowledge that as I get it rolling I will update it all to WPF and friends.
As I'm working through the code though it is getting cleaner I'm happy to say.
As for the data storage.... I've looked at and agonised over the options, everything from AWS and Azure and so on.... I am terrified of destructive bots DOS attacks etc. I have had it happen to me before and it sucked bad and totally ruined my application. I don't want to spare time to setting up Azure and to be grinding over that stone. I also don't trust those guys with the $ bill getting out of control.
I have decided on this data solution for now as I belief it will suffice for the current demand.
There will be one central Sqlite db located on the humble Bookings PC. Nothing will be allowed access this db except for this single application. This PC will be responsible for zipping and backing up the Sqlite db regularly to designated offsite locations. A dropbox folder might be enough to do the trick. (compare that to backing up SQL Server!)
Mobile devices (get this, it will stun you) will serialize their flight data to an XML file, zip it, and FTP it in to a drop folder on the web.
The PC will use FTP to check for new files, download them, unzip them, de-serialize them, insert them into the db.
The mobiles will keep all old flight logs as backups until manually removed, the ftp server will also keep a copy.
Anything to be used online, people viewing reports etc, will come via Views from a read-only database.
This ensures again that nothing outside can touch the main db. It is reliable. It is cheap as buttons.
It's a poor man's solution, I get that. But if it grows then we can spend money on a heavy duty db.
DbHub.io is another great tip - keep 'em coming. I will look into that for sure!
chrisjlocke commentedon May 5, 2021
Sounds like you've done your research and hit the same bricks I did. A company asked me for a multi-user application but they have zero infrastructure - no server, cloud, anything! Looked at Azure, etc, and they wanted something remote users could use (including mobile). Still unsure which path to trundle down, but at the moment a database application sitting on a virtual Windows 10 box that users can remote desktop into (and use the application as a remoteApp, so it just runs on their own desktop) is plan A. Looked at MongoDB as that was online and looked cheap, but the runtimes for the client was nuts - might as well installed SQL Server.
This part of dbhub.io is working, so could fit your needs. Using simple API, you can upload/download a database, and dbhub.io works similar to Git, so it has revisions, etc. I don't know how it works atomically, but do know it handles differences between two databases. In my use case, I'd want user A to upload a database, user B to upload a database, and they merge into a master, so user C downloads a fresh master. Absolutely no idea (yet) if that's do-able, or whether it might be more manual.
dbhub.io can also handle the 'viewing from a read-only database' part. That's because it only supports SELECT statements at the moment.
What are you writing the mobile part in? Mono? If that's using SQLite too, then dbhub.io could be the storage - create a database of your updates, upload it, then the other end just downloads and inserts ... but ignore me if you've already got that covered!
Again, good luck with it! Apologies for dragging this off-topic! 😁😂
fatscally commentedon May 5, 2021
In your case of merge. Select dbA as master, use dbB to "If not exists then insert into dbA" possibly add an "IsDirty" field to the tables to select only rows that have changed. Then dbhub(dbA). Would that work?
My mobile apps are Xamarin ready for MAUI. They will use the exact same db but with non relevant data stripped out.
All said there are many small office applications that simply do not benefit from Azure and AWS. I think people throwing their money at these options are not getting value for money. These companies know that and so they have "free" options, but I have been stung by these "free" options before and their hugely complex billing system that has to catch everyone out the moment they turn their heads. In short, I don't trust them with my money - I'm sure with the data they're doing a top job.
chrisjlocke commentedon May 5, 2021
It would, and that's what I'd do, but you have the minor issue of how your records are linked together. I always use an incremental integer ID field as the primary key, so in the logs, it might say user 4 has edited pilot record 6. This breaks as soon as you introduce this 'master' and 'slave' syncing system, where you're going to have two records with the same ID, so have to use some other field (GUID?) as a primary key. I remember going that route before (for some reason - can't remember why) where all keys were GUIDs. It meant one table just had numerous GUID fields and it was a bit of a pain to edit manually. Also a major pain to go down this route as an afterthought - a lot of programming has to change.
Again, technologies I've not touched on before, but interested in pursuing. Just going to watch this YouTube vid now.
It's all very complex and overkill. Was just looking at MySQL driver for .Net as I've normal Linux hosting going to waste and databases just sitting there with puppy dog eyes saying, "Use me!" but again, the runtimes seem crazy - 16 items/7 MB of DLLs and tut which I don't know if I need or not. That's one reason why I like SQLite - two files of around 1.5 MB is all that's needed.
Also just realised I've never said 'Xamarin' properly before! 😄
chrisjlocke commentedon May 5, 2021
lol. I've always used system.data.sqlite as my library of choice, but watching the above video and his Xamarin 101 series, he's using sqlite-net, which also has ORM in it .... ooooooh.
fatscally commentedon May 6, 2021
GUID we're most likely made for the problems of collision.
If you know the likely range of your data you could Seed the field, appA Id 10,000-19,999, appB Id 20,000-29,999 ....