Dbf Components Access ... [SOLVED]

[1HuntnMan]

I have an app with main form and 3 forms thus far. Using TDbf because it's to be a 1-3 users at the most. I have been building the forms loaded from the main form and placing the Dbf and Datasource on each form. Some are redundant. Would it be better to have a form with just the TDbf's on it and each form using that form with DataSources on each form. Basically the Database form would just be used by other forms.

[TRon]

@1HuntnMan:
it is called datamodule see also wiki: https://wiki.freepascal.org/Data_module

[Packs]

Can we do the index in dbf

Can we encrypt the table

How to use multi user

[TRon]

@Prakash:
Do you know that it is considered rude to hijack someone else's thread ?

If there is additional content (related to the topic) that could be added to a thread then that is encouraged but you don't even seem to have the decency to wait until the Original Poster has responded to the answer directly related to his question.

In your culture it might perhaps be considered smart or normal to hop on a(ny) bandwagon simply because there is an overlap in the topic at hand but in programming forums it is considered very rude to pollute an existing thread with (all kinds of) side questions especially when these questions are asked before the original question from OP was answered. The questions you asked in itself are obviously caused by the fact that you are too lazy to read a tutorial and/or manual and/or does not want to google for answers. Such behavior can even be perceived as trolling.

Can we do the index in dbf

yes.

Can we encrypt the table

no (not by default functionality).

How to use multi user

read the tutorial (which also contains a link to the official tdbf manual)

Next time when you ask a question consider asking because it has an actual direct relation with existing code or idea and not a generic questions for which the answer can be found/located in about 2 jiffies. Doing so will prevent from aggravating answers/responses.

Ofc. take it for the 2 cents that my response isn't even worth.

[1HuntnMan]

TRon, thanks and Wow!  Reading a bit, this is exactly what I was aiming for! Thanks!
But another question, the examples are describing a SQL database.  I'm just using Dbf because it appears easier to just build tables and use the Lazarus components while developing the app.  The way it sounds, which I just created for this app.  Do I put the Dbf table components on the DataModule.  Then, let's say on my Client form just put the DataSource property on it because all the DBEdits, DBLookUpComboBox's, etc. are just wanting the DataSource property. That also means that the Client unit would have the Datamodule unit name included so the DataSource's could see it's coresponding Dbf in the Datamodule.  Does this make sense, am I on the right track?

[1HuntnMan]

Okay, created a DataModule and moved all my Dbf table components to the DataModule form.  Removed them from all the other Forms leaving the DataSets on those forms and pointed them all to the correct Dbf's on the DataModule.  Compiled and Lazarus is having an issue with the Var declaration in the DataModule unit.
Here's the error:  datamodulepms.pas(32,1) Fatal: Syntax error, "identifier" expected but "IMPLEMENTATION" found
from these lines in the DataModule unit:

unit DataModulePMS;

{$mode ObjFPC}{$H+}

interface

uses
  Classes, SysUtils, dbf, DB;

type

  { TDataModulePMS }

  TDataModulePMS = class(TDataModule)
    DbfFirmTypes: TDbf;
    DbfSTProvCodes: TDbf;
    DbfRefTypes: TDbf;
    DbfReferences: TDbf;
    DbfCountries: TDbf;
    DbfContacts: TDbf;
    DbfClients: TDbf;
    DbfAppmts: TDbf;
  private

  public

  end;

var
  DataModulePMS: TDataModulePMS;

implementation

{$R *.lfm}

end. 

[Josh]

could be
unit name is same as var, try renaming the var

unit DataModulePMS;
var
  DataModulePMS: TDataModulePMS;

note I personally keep unit names all lowercase as some OS's are case sensative

[wp]

The case in the unit name by itself does not matter (and I do prefer it to be in camel-case for better readability), but it is important that the unit is saved in lowercase name since Lazarus seeks for a unit in lowercase as fall-back if it does not find it in the exact unit name case. But Lazarus normally does this by default. So, when you save a unit as "DataModulePMS" the unit name (the word in the first line of the unit) is written exactly like this, but the file is saved as "datamodulepms".

Yes, the equality of the unit name and the variable name is the problem. Rename the unit to "uDatamodulePMS", or something similar - I usually put a project-typical prefix in front of the unit name instead of the "u" (which stands for "unit").

As for the initial question whether to have also the TDataSource components on the datamodule, I'd recommend to put them on the forms where they are needed. This is a bit unusual because many text books tell to put them on the datamodule next to the dataset components to which they are linked. But when there is any chance that you once might switch the database system, maybe from DBF to SQLite3, I think you have less work when the datasources are not in the same unit as the datasets; and you could even run both systems in parallel for some time and for easier testing.

[1HuntnMan]

Thanks, I agree. Moving all the Dbf's back to their appropriate forms where they are needed. I attempted to rename all names to all lower case but that didn't cure the error.
PROBLEM SOLVED!