The offical for ZeosLib 7.3 Report problems, ask for help, post proposals for the new version of Zeoslib 7.3/v8
Quick Info:
-We made two new drivers: odbc(raw and unicode version) and oledb
-GUID domain/field-defined support for FB
-extended error infos of Firebird
-performance ups are still in queue
In future some more feature will arrive, so stay tuned and don't hassitate to help
aehimself wrote: ↑07.05.2020, 20:09
I guess if you delete it from GitHub only and try to push, it will either fail or recreate the remote branch; not sure. The real question is how branches are created when exporting via svn-all-fast-export...? Even if you delete your local branch, it might recreate it again just to return to the original state.
Anyhow; I don't mind my name being present on the unofficial repository ^^
Just to make sure what we are talking about. The current process looks like this:
sync a local copy of the Zeos SVN repo by using svnsync
use svn-all-fast-export to copy new changes from the local svn repo to a git repo
push any changes from the local git repo to the github repo using "git push github --all"
My hope would be that deleting the branch from the github repo would have no negative effect because the aehimself branch in the local repo should see no more changes and so git should not see any reason to try to push anything from the aehimself branch to github ever again. Does that make sense?
Honestly, the worst thing that can happen imo is that something goes horribly wrong and the GitHub repository has to be recreated. Since I'm the only one who forked it until now - this will not have a huge impact. I'll just re-fork and re-push my own changes. Alas, following this thought the branch can also stay.
What I'd do is to delete the local branch, and start the sync (and fast export). Then check if the -aehimself branch was recreated or not. If not, just delete the branch on GitHub (git push --all means you are pushing all local branches. If there's no local -aehimself branch, it will not even be attempted to be pushed). If yes - then some help digging and googling on which step and how it is creating the branches.
Delphi 12.1, Zeos 8 from latest GIT snapshot
Using:
- MySQL server 8.0.18; libmariadb.dll 3.3.8
- Oracle server 11.2.0, 12.1.0, 19.0.0; oci.dll 21.13
- MSSQL 2012, 2019; sybdb.dll FreeTDS_2435
- SQLite 3.45.2
I encouter a strange problem. When I compile already existing applcations I get an error when I try to open a report. I did some tests and when I drop the old query component and use a new one from zeos 7.3 then everything works. Do I have to change all query components when I use 7.3 with lazreports?
When I use zeos 3.7 build 5939 I don't have problems.
I use Windows 64 bits (1909 - 18363.778)
Lazaus 64 bits 2.08 R62944
fpc 3.,04
zeos 7.3 build 6513
SQLite version x64 3310100
You do not have the required permissions to view the files attached to this post.
tkamphuis wrote: ↑12.05.2020, 10:04
[...] when I drop the old query component and use a new one from zeos 7.3 then everything works[...]
Do you use persistent fields, i.e. field components that are inserted in the form using the fields editor?
Normally you don't have to replace the query components. I can only assume that somehow some settings change or the field types change.
Yes the problem is with the persitant fields, but I need that for reference to from other queries. In the past that was not a problem. The field types are not changed.
When cross compiling from GNU/Linux system (Debian and it's derivate) to Windows 64 there are some "caps" filename problems.
In files ./dbc/ZDbcAdoMetadata.pas:67, ./dbc/ZDbcAdo.pas:131, ./dbc/ZDbcOleDBStatement.pas:244, ./dbc/ZDbcOleDBMetaData.pas:52, ./dbc/ZDbcOleDB.pas:153 in uses there is ZDbcOleDBMetadata but file is called ./dbc/ZDbcOleDBMetaData.pas, it probably should be renamed to ./dbc/ZDbcOleDBMetadata.pas (with lowercase d).
In file ./dbc/ZDbcAdo.pas:131 there is a uses clause unit ZDbcAdoMetaData and it should be ZDbcAdoMetadata.
After this changes compiling is succesfull. FP IDE is CodeTyphon 7.10 but because it's a OS problem this problem is probably same with Lazarus.
vbazovic wrote: ↑13.05.2020, 10:29
./dbc/ZDbcOleDB.pas:153 in uses there is ZDbcOleDBMetadata but file is called ./dbc/ZDbcOleDBMetaData.pas, it probably should be renamed to ./dbc/ZDbcOleDBMetadata.pas (with lowercase d).
In file ./dbc/ZDbcAdo.pas:131 there is a uses clause unit ZDbcAdoMetaData and it should be ZDbcAdoMetadata.
Your suggestions have been applied in Revision 6520. Best regards,
tkamphuis wrote: ↑12.05.2020, 14:03
Yes the problem is with the persitant fields, but I need that for reference to from other queries. In the past that was not a problem. The field types are not changed.
coud you send me the lfm-file of your form before and after the change - meaning the not working form file and the working form file? Also the declaration part of the pas file is needed to see what field types are generated by Zeos.
I checked "demo" and in Lazarus 2.0.8-Win64 entries about persistent fields are not saved to the unit .pas file.
In .lmf they are.
And in uses are missing entries: ZAbstractTable, ZAbstractRODataset, ZAbstractDataset, ZAbstractConnection; The same happens in a newly created application.
Everything is fine in Delphi 10.3.3-Win32.
They are in .pas and in .dfm.
