Automatic Data Entry

[Peter De Berdt]

On 29 Oct 2004, at 03:49, Chuck Pelto wrote:

>
> On Oct 28, 2004, at 6:03 PM, Kim Kohen wrote:
>
>> G'day Chuck
>>
>>> Unfortunately, the tutorials, all of them, are not very good.
>>> Especially if one is new to SQL. I've addressed this with Ruslan.
>> ••••
>> If I could get my head around it I'd write a tutorial myself:)
>
> I was of the same mind, but considering that other third-party 
> tutorials didn't seem to be keeping theirs up to speed, I suspect that 
> the only one with the real motivation to do a good tutorial and keep 
> it current is the manufacturer.
>
To defend Ruslan, most other databases don't have the complete SQL 
explanation in their manual either, SQL is a standard, so you can just 
look up the specs. However, Valentina 1 only supports a subset of SQL, 
so I agree it's sometimes hard to know what you can and what you can't 
use.
But I agree to the statement that in order for Valentina to become one 
of the serious players on the market, it needs a clear and educating 
manual, if it were my company, I'd even outsource it. Programmers 
always tend to assume the end user is smarter than he/she really is :-)

>>> I can come up with work-arounds on the matters of automatic data 
>>> entry.
>>> That's not too much of a problem. But it would be a nice feature to 
>>> see
>>> available. Especially the serial number aspect.
>> ••••
>> I know people will refer to the RecID but I'm really struggling to 
>> come to
>> grips with not having my own ID field. It's been the first field in 
>> every db
>> I've created in the last 10 years.
>
> You still need a key/ID field in SQL, as far as I can tell. It's just 
> that its not going to be as automated as we are used to in FMP. We'll 
> need to build a routine to generated that data to go into that field.

You can use the RecID (and in Valentina 2, you have primary keys and 
foreign keys too, those are the ones you're looking for), but if a 
record is deleted, the RecID of that record will be reused when you 
create a new one. I believe this has also changed in Valentina 2.
>
>> The auto-entry thing can be overcome pretty easily. In RB I have a 
>> 'sheet'
>> for a new record where people enter basic information. It would be 
>> easy to
>> just hard-code a constant into the SQL insert statement to give a 
>> default
>> value to a particular field every time a new record is created.
>
> Yes, the routine can be accomplished inside of RB and the data passed 
> to the key field in the SQL tables, as necessary. More drudge, but I 
> suspect a module can be developed and passed from RB app to RB app so 
> we don't have to recreate the wheel in each new project.
>
Exactly, that's object-oriented programming. You just let the object 
handle your automatic data entry. I wouldn't put it in a module, but in 
a class (modules are like scripts, they're global, but it's not a good 
practice to use them if you can use a class for it). This class would 
then do record updating, record inserting, record deleting and all 
other database operations for you. If your class is well written and 
you don't use direct database operations from within the rest of your 
application, you could even decouple the database backend from your 
frontend application. Switching databases then becomes a breeze, as you 
only have to rewrite the class that interfaces with the database (look 
at a lot of PHP solutions, they have database abstraction, which allows 
you to choose your database backend).

I want to emphasize switching from Filemaker to REALbasic requires you 
to turn a switch and start thinking differently. If you don't, you'll 
have the same problems you have with Filemaker in no time: speed 
issues, unmaintainable code, broken code, ... If you are really serious 
about object-oriented programming, get yourself some books on the 
subject, don't forget to get "Design Patterns" once you really know OO, 
it's like the programmer's bible.

Good luck!

Best regards

Peter De Berdt