Main Area and Open Discussion > General Software Discussion
SQLNotes...what is it exactly?
superboyac:
Hi Pierre, I noticed the new "Full Hierarchy" option. I still don't know how to fix my music grid. Did you fix the issue with the hierarchies that have more than 500 items? I still can't get my original hierarchy, no matter how I tweak the options. You should have a copy of my database, it's in the last email I sent to you.
I'm still wondering about the whole renaming grids process. I get your point that if the checkbox was also renamed, then the equations would potentially get screwed up. How about using an ID number similar to the Item ID number that you are currently using, except the number will apply to grids. That way, if grids are renamed, the ID number stays the same and maybe it won't be as confusing (like having " " being entered for the MusicItem field even though I'm now using Item).
Armando:
How about using an ID number similar to the Item ID number that you are currently using, except the number will apply to grids. That way, if grids are renamed, the ID number stays the same and maybe it won't be as confusing (like having " " being entered for the MusicItem field even though I'm now using Item).
-superboyac (February 22, 2008, 11:54 AM)
--- End quote ---
If that isn't already functioning that way, I think that this a good idea : ID numbers for grids AND fields (fields might be functioning that ways already though, haven't checked...), independent from the names. Equations, formulas, etc. would only deal with the underlying ID number.
superboyac:
As far as I know, only the items are using ID numbers. Obviously, Pierre knows the implications of this better than us. But just by speculating, assigning ID numbers to grids and fields has pros/cons. For the grids, the benefit is that renaming the grid won't cause confusion for the user like I'm experiencing. On the other hand, it's much easier and more intuitive to use field names instead of numbers in equations. Let's say you use a field name in an equation and then you rename that field. Do all the equations get updated with the new name? Or do the equations stop working because that name no longer exists? I don't know. As Pierre said earlier, when a grid is renamed, there's an internal workaround where even though the old name isn't being used anymore, it still is including a blank entry " " so that the item still can be recognized as part of the grid (regarding that checkbox field that determines what the grid will show).
Armando:
If I understand correctly, for ID numbers to be user friendly, Grid/field names would have to be always transparently translated into the underlying ID numbers (normally "invisible" to the user). The problem is that even in the case where SQLNotes would be aware that 2 different names are used for the same field/grid, it could become confusing for the user... who might not remember that 2 (OR MORE) different names are in fact used for the same grid/fields!
In the ideal idiot proof world, SQLNotes would correct all the formulas when you change the field/grid's name... :huh:
Like you said, "Pierre knows the implications of this better than us"....
suleika:
Thank you, superboyac and Armando, and all contributors here! It was a long thread, but it broke the ice of my understanding about how this program works. And thank you, PPL, for all your posts here. I hope you are still around and reading - I'd prefer to post here for now but let me know if you want me to cross-post onto your forum.
I'm more than curious to try SQLNotes but I'd like to understand just a little better how it can play as a relational database. The reason I ask is that although I'm no expert, I have used Access and HanDBase before, both of which are relational, and I know how to go about creating fields and items in that kind of structure. I just can't get my head around how that translates to SQLNotes. I'm going to play with a few items and fields and grids, but if anyone has already been through this thought process and can give me some pertinent metaphors or examples, I'd be really grateful.
An example of the "relational" sort of thing I would want to use it for is a historical work database for my singing gigs (to help me remember what I've done!). I would be listing jobs, singers, conductors, venues, dates of performances, works performed etc. Any given singer might have performed in any number of jobs with me, any work might have been performed in any number of jobs, any job might have many works performed and even more than one conductor, and a work would have a composer and might have other properties such as translation or edition.
I've been seriously considering using a wiki for this, but although I love wikis I find them a bit slow and/or clunky, and even in the clever Wikidpad, where it's possible to auto-extract lists of "items" with certain "fields", I would have to learn some python (a lot for a beginner like me!) to generate useful lists and views. I considered a serious database solution but HanDBase on the desktop has a horrible GUI and I try to avoid MSOffice as much as possible. I have a feeling SQLNotes would be ideal here.
I have various lists and spreadsheets dotted around (in Excel, in PhatNotes, in an old Wikidpad, and in Outlook) that I would love to consolidate. I've procrastinated the consolidation (and the historical work database) because I imagined I could find something sophisticated enough but also syncable with palm/windows mobile, but I find that more and more I use my handheld as a static device, to which I write information, but on which I edit very little. So now I'm after something that works best for me on the desktop but which can export to readable formats like HTML or to spreadsheets.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version