Re: One more (maybe stupid) database question


"Maarten Wiltink" <maarten@xxxxxxxxxxxxxxxxxx> wrote in message
news:4b0bdb7b$0$22944$e4fe514c@xxxxxxxxxxxxxxxxx
"Paul E. Schoen" <paul@xxxxxxxxxxxx> wrote in message
news:uTLOm.18288$gd1.12022@xxxxxxxxxxxxxxx

Everything seemed to be working just fine in my application, but I
found that the edits I was making in a dbGrid were not being posted,
but then I found that I had to set dgAlwaysShowEditor as True, or
else the change had to be posted by using the Post control on the
dbNavigator.

You're chasing side-effects again. Manually posting is normal and
expected, and AlwaysShowEditor sounds wrong for a property with the
effect of changing that. Isn't there an AutoPost or similar property
somewhere?

With the dbGrid, there is a control (Up Arrow) which specifies that a
record is to be edited, and another (Check Mark) that Posts it.
AlwaysShowEditor just automatically enables Edit when a record is selected,
and it is Posted when another record is selected.

This is another problem I have noticed. If I edit a record and then switch
to another tab *** for a different table, the changes do not get posted.
I even added an OnExit handler that checks the table for Edit State to Post
the change, but apparently it does not stay in the Edit state when the Exit
event fires.


[...] I really don't fully understand the TDatabase component, but I
see now that there is a DataSets property where multiple DataSets may
be entered. This makes sense for a database with a single file, and I
suppose it can also encompass the multiple files of a dBase file
structure.

A TDatabase encompasses the abstraction of a database and connections
to it. It doesn't matter if the database is in one file, or several,
or only accessible through a database server. There is a logical
database that you can run queries against. No need to ever think of
files.

Oh, and local 'table' components are *wrong*, too. Reading records is
done through (select) queries. Changing (and adding and removing)
records is done through (update/insert/delete) queries. Clientdatasets
are for caching records (and modifications!) locally.

This application is designed to be local in nature, with the database in
its Application Data folder. I use a Select Query to obtain a sorted list
of TechIDs, for instance, but I write updates directly to the tables. It
appears that Queries are a useful concept, as they provide a method to use
a sort of script to make changes to a database, but I think it adds a level
of complexity that is not needed for my purposes.

I think perhaps I need to rethink the entire concept and its
implementation. First I'll try to explain just what I'm trying to do. This
is mostly for my benefit in organizing my thoughts, but I'd appreciate
suggestions. I know that much of this may be very basic stuff.

In my form fmReclData, I have various combo boxes and edit boxes which
correspond to items which are fields in various tables. For instance, I
have a cbTechID which lists TechIDs from a table tblTechs. The user selects
one or may add a new ID. I would like to show the available TechIDs along
with the second field in the tblTechs, which is the full name, but at this
point I don't know exactly how to do that. In MS Access I can show selected
fields, and have the contents of the combo box linked only to the TechID
field.

I tried using a TDBLookupComboBox. I set the ListSource as dsTechs, and the
DataSource as dsResults, which is a table on the fmOrtResults form. I ran
into a minor problem when I tried to select the DataField, as it reported
that the file corresponding to the table was not found. I have the files in
a different folder. So I copied them into the project folder and I selected
the TECHID field in the results table.

When I ran the app, nothing appeared in the combo box, but I found that I
had to Open the associated tables. I am opening and closing the tables as
needed, but probably I should open them all while I am doing anything with
the database and then close all when the application closes. Perhaps this
is where the TDatabase component becomes useful, so that individual tables
need not be opened and closed as I am doing.

But with this TDBComboBox control, it changes the value of the field in the
first record of the table tblResults. But I really just want the text of
the ComboBox to change. When the user runs a test and saves it, then I
create a new record and put the TechID there.

The other ComboBoxes are similar. At this point I am using a Query to
populate the lists of regular ComboBoxes, and checking for a new entry
which prompts the user to add another record with the FullName field.

I would like to do this the "right way". Not having much experience with
database programming, particularly in Delphi, I have run into a number of
snags and then I've come up with workarounds rather than the proper way of
doing what I want. The examples I have seen seem to be incomplete or have
features that I don't need and can't quite comprehend. I don't really have
the time to learn all of the concepts to implement them properly. I am also
involved in the hardware design and manufacturing of this product along
with other projects, and the database portion was a recent addition because
the person I was working with was not doing so in a timely manner, and also
not in the way that I felt it should be done. At this point at least one
customer is evaluating the system as I have envisioned it. My former
partner may also show customers his implementation, and they may then
choose which they find better.

I'll have another go with the Help and tutorials and examples, and try a
few other ideas which may be closer to the "correct" way to accomplish what
I want.

Thanks,

Paul


.

Quantcast