[SOLVED]DBGrid- How to populate

[What I can do]

FAT!  FAT!  FAT!   
see above for any links
These people are wonderful in helping me and I thank them very much for donating there time and knowledge

NOTE: This is far more complex then it use to be and so is our technology world many different make and manufactures
have to share information of both data and user interface.

I finally began to see what needs to talk to what;
1) there is a user setting (configuration) in the OS (win10) that needs to be configured
   a. install ODBC 64
   b. Add a [User DSN]
      i. pick "Microsoft Access Driver (*.mdb, *.accbd)"
      ii. Give it a name that makes since like "Access64"
      iii. [Select] browse to your data base file
    [save and/or ok] to acknowledge and close everything out

You have just completed the OS portion and now your ready to start you Lazarus project
1) Project new application
2) drop on DB component and modules
    a. like DBGrid, TODBCConnection, TSQLTransaction, TSQLQuery , TDataSource
3) Test db connection with the  TODBCConnection and configure it
    a  only one setting [DatabaseName] = "Access64" as created above
    b. you now test it,
         set [Keep connected] to TRUE
    c. The big test -- [Connected] to TRUE
at this point if you get any errors they must be resolved.
FAT1= I remarked out all code from many examples that make any setting to the ODBCConnection1 parameters.
FAT2= do not assign any data base files leave blank
FAT3= do not use any DSN files or reference there of
FAT4= rem out all settings to Dataset1 and DBGrid1
FAT5= rem out all setting to SQLQuery1

Now you need to build the communication links of the tree
OS talks to your data base file via UserDSN confuguration "Access64"
ODBCConnection1 talks to [DatabaseName] "Access64" from the ODBC UserDSN settings
                          and to [Transaction] SQLTransaction1
SQLTransaction1 talks to [Database] ODBCConnection1  (not circular but two way communication)
                        also set [Action] to caCommit
                               set [Active] to TRUE
SQLQuery1 talks to [Database] through ODBCConnection1
                and to [Transaction] to SQLTransaction1
                set [UsePrimaryKeyAsKey] to false  (should be default)
                set [SQL] top line "SELECT * FROM car" (car is the name of my table)
DataSource1 talks to [DataSet] SQLQuery1
DBGrid1 talks to [DataSource] DataSource1

The only programable code I use now is on "FormCreate"  is  SQLQuery1.Open;
Everything is hard set and nothing programable which makes this my measuring stick.
This is my first successful full view only test project.  now I have a starting point to build with.
thanks to everyone

[wp]

Congratulations that you were able to do a big leap forward.

Just a comment from my personal opinion: As I already wrote above I always use DSN-less configurations since it gives me more freedom in using the database: I can copy the application and the database to another computer without having to take care of DSN configuration which maybe I am not even allowed to do there.

[What I can do]

Thank you WP
I agree with you but I had to find at least one successful point to start from.  All my OS are Windows  for now but I would like to port to Linux.  I'm trying to eliminate the DSN file all together and just have everything internal code. Your right it makes it easier on me to move to another computer.  I have several system and it's sort of like one is for developing and the other is for using. Plus I have helped a few other people with small utilities and apps for something they needed. It is nice to just give them the code and it's done.  When I used Delphi 2006 enterprise I developed DBunit to the point of just a few lines of code would do a lot and my goal is to do the same with Lazarus . Thank you for your help.

The same to HANDOKO Thank you for your support as well
Just and update I have manage to eliminate most of the DSN file and have discovered that the DBQ has to be full path short naming convention.  Now all I have to do is work on the driver still get an error inside code with out the DSN .

[Handoko]

Glad to know you finally managed to make it works.

If you're looking for a database that is easy to distribute for your programs, I would recommend SQLite. It requires zero admin, licensed in Public Domain, for distributing you only need to provide the client library, which can be easy found and downloaded from web. Most Linux distros have SQLite installed by default. SQLite is not specialized for multiuser environments, but it supports multiuser at once. All the information you need can be easily found in the Internet.

If you want to see a basic demo of Lazarus - SQLite, here you can try this:
https://forum.lazarus.freepascal.org/index.php/topic,65185.msg496461.html#msg496461

[egsuh]

If you're looking for a database that is easy to distribute for your programs, I would recommend SQLite.

The only problem with SQLite is that it does not support stored procedures.

[cdbc]

Hi

The only problem with SQLite is that it does not support stored procedures.

Are they __really__ needed in a single-user database?!?
I tend to connect them with larger scale DB-operations...
Regards Benny

[Thaddy]

The only problem with SQLite is that it does not support stored procedures.

But it does support UDF's and Triggers. With those two you can come very close to stored procedures.

[Zvoni]

But it does support UDF's and Triggers. With those two you can come very close to stored procedures.

Correct.
In regards to UDF, though, the "standard"-sqlite3conn doesn't offer to register such an UDF.
You have to modify/extend sqlite3conn (Keyword Class-Helper),
which i have done to support regex within SQLite-SQL-Statements

[egsuh]

Are they __really__ needed in a single-user database?!?

It's not definitely necessary, but I think stored procedures have advantages in keeping data consistency and overall maintenance. For example, I can change only stored procedures when I want to add some more features to database design and table structure, keeping Lazarus program part without change, or vice versa.

[Zvoni]

Are they __really__ needed in a single-user database?!?

It's not definitely necessary, but I think stored procedures have advantages in keeping data consistency and overall maintenance. For example, I can change only stored procedures when I want to add some more features to database design and table structure, keeping Lazarus program part without change, or vice versa.

That's actually the reason why i store the SQL-Statements themselves in a separate table within the sqlite-database, and not in the source of my Lazarus-Frontend.
As long as i don't change the "interface" of the Statement, i can change the statements without having to recompile my Frontend.

A "somewhere in the middle of it"-approach might be to source out any Data-access to a separate library (dll, so), so if any changes appear you only have to recompile the Lib.
The constraint of "don't change the interface of the Statement" still applies, though

[egsuh]

The constraint of "don't change the interface of the Statement" still applies, though

This is especially important as I cannot remember the exact codes after a while since I first wrote the codes.