Recent

Author Topic: Dbf Components Access ... [SOLVED]  (Read 5418 times)

1HuntnMan

  • Full Member
  • ***
  • Posts: 183
  • From Delphi 7 to Lazarus
    • NewFound Photo Art
Dbf Components Access ... [SOLVED]
« on: October 31, 2023, 08:43:00 pm »
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.
« Last Edit: December 15, 2023, 03:22:56 pm by 1HuntnMan »

TRon

  • Hero Member
  • *****
  • Posts: 2487
Re: Dbf Components Access ...
« Reply #1 on: October 31, 2023, 08:44:54 pm »
@1HuntnMan:
it is called datamodule see also wiki: https://wiki.freepascal.org/Data_module

Prakash

  • Full Member
  • ***
  • Posts: 169
Re: Dbf Components Access ...
« Reply #2 on: October 31, 2023, 10:29:31 pm »
Can we do the index in dbf

Can we encrypt the table

How to use multi user

TRon

  • Hero Member
  • *****
  • Posts: 2487
Re: Dbf Components Access ...
« Reply #3 on: October 31, 2023, 10:53:55 pm »
@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.

Quote
Can we encrypt the table
no (not by default functionality).

Quote
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.
« Last Edit: October 31, 2023, 11:01:31 pm by TRon »

1HuntnMan

  • Full Member
  • ***
  • Posts: 183
  • From Delphi 7 to Lazarus
    • NewFound Photo Art
Re: Dbf Components Access ...
« Reply #4 on: November 01, 2023, 08:20:53 pm »
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

  • Full Member
  • ***
  • Posts: 183
  • From Delphi 7 to Lazarus
    • NewFound Photo Art
Re: Dbf Components Access ...
« Reply #5 on: November 01, 2023, 10:04:19 pm »
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

  • Hero Member
  • *****
  • Posts: 1273
Re: Dbf Components Access ...
« Reply #6 on: November 01, 2023, 10:19:00 pm »
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
« Last Edit: November 01, 2023, 10:21:25 pm by Josh »
The best way to get accurate information on the forum is to post something wrong and wait for corrections.

wp

  • Hero Member
  • *****
  • Posts: 11902
Re: Dbf Components Access ...
« Reply #7 on: November 01, 2023, 11:16:55 pm »
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

  • Full Member
  • ***
  • Posts: 183
  • From Delphi 7 to Lazarus
    • NewFound Photo Art
Re: Dbf Components Access ...
« Reply #8 on: November 02, 2023, 01:44:45 pm »
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!

 

TinyPortal © 2005-2018