Jump to content

Hans J. Ellingsgaard

Members
  • Content Count

    101
  • Joined

  • Last visited

Posts posted by Hans J. Ellingsgaard


  1. The problem is your join in the query. Sometimes FireDAC is smart enough to write an update script that's ignoring the join fields, but if not, then you have to write the update query yourself. If I remember correctly there is a description of how to do it in Cary Jensen's book. ( I saw you mentioned it in an another post)


  2. 3 hours ago, limelect said:

    FDMemTable1.CloneCursor(ProjectsFDTable);<< 

    Have you tried using a FDQuery with a where clause, where you select just one record, instead of a FDtable component?


  3. 18 hours ago, limelect said:

    The strange behavior is now on insert where I cannot pinpoint the 

    problem. I am not sure where is the problem yet.

    Do you use a FDQuery for insert? If that's the case do you hava a "select * from" in the sql command, or do you use an "insert into command"?

    You could try to write a direct insert command and use a FDCommand component to see wath's happening.


  4. 4 hours ago, limelect said:

    @Hans J. Ellingsgaardmaybe it is feasible for a search but not for insert where I have that problem too.

    While searching for a solution on searach I found that if I have an EMPTY text to search I get a memory problem

    Is that search based on a table component? If that's the case you'll end up loading all records into memory. You can instead make a search with a query and a where clause.


  5. My guess is that your tables has a lot of records, or each of your records holds a lot of data, and when you opens it, with a table or query, you get all the records into memory.

     

    If that's the case, you will need to limit the number of records with a where clause in your query. You could also limit the number of fields for each record in an overview, and then select all fields only for an active record.


  6. You can usa an API like https://www.ipify.org to get your public ipaddress.

     

    When that is said, this sound strange. Do you have a printer that can be called directly with a public ipaddress, do you not have a vpn or some other secure connection to the office network?


  7. On 6/5/2022 at 3:59 PM, TurboMagic said:

    Some Firebird documentation about generators I just read recommends to NOT directly query a generator like that for master/detail tables, as in multi user scenarious you cannot be sure whether somebody already further incremented the generrator etc.

    I can not see why this should be a problem, you got your ID and stick to it until your record is finally posted to the database. You use it as a primary key on your mastertable and a foreign key on the detail table. The generator is running outside the transactions, and you are guaranteed to get a unique value each time you request for an ID.


  8. On 5/13/2022 at 10:26 AM, Fons N said:

    In the OnConstrainedResize event of the Form include the following:


    MaxHeight:= Screen.WorkAreaHeight;
    MaxWidth:= Screen.WorkAreaWidth;

    You could use the Constraints property of the form instead of using the Event.

     

    Self.Constraints.MaxHeight := Screen.WorkAreaHeight;
    Self.Constraints.MaxWidth := Screen.WorkAreaWidth;
     

     

    • Like 1

  9. If you place the dll files manually into the windows system folders, you'll need to run regsvr32 to register them in Windows. If you use the installer it will register them for you. If you place them in your programs root folder, there is no need for registration.


  10. One way to get around that datetime field, is to create a View on the datbase, where you cast your datetime field to a date field, and then connect the table component to the view instead of the query.

     

    Is there a specific reason why you want to use a table compnent instead of a query?

×