Date: prev next · Thread: first prev next last
2014 Archives by date, by thread · List index 

Hi :)
Macros are code running on a desktop machine right?  So don't they take up
cpu cycles?  If the macro code is then running stuff through Sql code then
it's going to take more Cpu cycles than just running Sql alone.  So in
terms of network traffic they might not count for much but in terms of
end-user experience it might be critical on low-spec machines.

As for visualisation of data SQL statements built-up through the Base gui
can show the resultant data neatly in a table that looks like a
spreadsheet.  I don't think macros can do that.

A proper programmer might be able to visualise data more easily without the
distraction of something being right in front of her/his eyes and thus
obscuring abstractions and specific cases at extreme ends of the possible
data but most of us need to see something 'concrete' before we can begin to
start on that sort of visualisation.

On the other hand if macro language is easier to understand and code for
then that might well be the best route for surest victory right now.
 Perhaps look into using a gui to build Sql statements after you have first
got something running using macros.  "Release early and release often".
 The macro version would be the 1.1 and the non-macro would be the 2.0 with
advantages such as being faster.  People could buy into either one without
having to worry about incompatibility issues when trying to communicate
with people using the other.  Also learning the LO macro language means you
can write macros to do other things and unlike with MS macros don't have to
worry much about those macros becoming out-dated by the next release of LO
or AOO or AndrOO or whatever.

Regards from
Tom :)




On 7 May 2014 08:20, Fernand Vanrie <sos@pmgroup.be> wrote:


On 6/05/2014 22:35, Girvin Herr wrote:


Tom & Milica,
No! No! No!  I am not offering to do the work.  I apologize if I somehow
implied that.  I  have zero experience writing LO macros of any sort.  I
was just suggesting to avoid macros wherever possible. Recreating data
entry forms and reports when there is a need to migrate to another client
(front end) is enough of a problem without having to re-write macros too.

I use the Base query editor as Tom suggests, which is a nice GUI shell
around the SQL, to create my table data relationships, aliases and sorts.
 It is very similar to what Access 1.1 had to define similar relationships.
 It works great.  If you want to see the underlying SQL, it can switch
modes to show the SQL and even test run it to see the resultant output in
table form.

I was just suggesting to look at using a query or two rather than macros,
wherever possible.  Another aspect of this is that a query should run the
actions, such as a sort, on the database server (back-end) and should run
faster than a macro running in Base.


Using a proper SQL server + Macro's + dialogs (no forms) but using the
dialog controls to visualise the data is not the easyist way but opens a
never ending route.

 I am curious: Does the Base macro "engine" run in Java?  Has anyone

tested this probable speed difference?


not the macro's make a difference , you just use a macro visualise the
data and to pass the SQL statements to the server who change , update or
delivers the data. Only the connection with your server and the data
volumes influence the speed.

 Girvin




On 05/06/2014 03:52 AM, Tom Davies wrote:


Hi :)
Can you post some of the old macros as plain text and give a rough idea
of
what each does.  SQL is usually easier because you get a nice gui to do a
lot of the work in a nice point&click way.  Some of the algebraic
formulae
might be much the same or perhaps a little less convoluted.

Plus Sql is more generic and less dependant on specific product and
versions.  On the other hand the LibreOffice/OpenOffice macro language is
also much less version-specific than MS macros.

I'm not certain that Girvin is offering to do the work for free.  Knowing
him he probably is but it might be better if there was a potential for
payment for work done, unless exchange-rates make that unworkable (as
often
happens).
Regards from
Tom :)



On 6 May 2014 07:45, milica <miljkovic.milica.83@gmail.com> wrote:

 Dear Girvin,

I have that base that we use in our workshop like warehouse
management,(select product, type amount that needs to be added/removed
from
warehouse and macro does it) and also base needs to create work orders
based on calculation (for every product, how many half products there
is to
be made) times number of products needs to be made,and then write that
on
some report.
I pretty mush did all the work in LO Calc, and the SQL is too much for
me
currently. And I do that for personal use, since we have to switch from
XP/Access to Ubutu/LO on our workshop computer.
I cannot ask you to do that work for me, and I'm not sure If I could
handle
that myself.
Thanks,
Milica




On Tue, May 6, 2014 at 12:07 AM, Girvin Herr [via Document Foundation
Mail
Archive] <ml-node+s969070n4107732h84@n3.nabble.com> wrote:

 I have not been tracking MS Access system design since version 1.1, but

back then Access did have an external database back-end (server) engine
called Jet.  Jet was bundled in with Access, much like Base uses
HSQLDB,
but I think it could be used by other front-end clients than Access.
So, the MS Access client-server  topology was not that unlike Base.
Base just allows one to get out of the MS Access proprietary "silo" and
allow much more control of the database system.

For the record, I am using MySQL with Base, soon to be switching to
MariaDB.  I have not needed to use any macros in my work with Base
forms
or reports.  I have made it a point to avoid macros because they are
very client-dependent and they would lock me in to a specific client,
much as the MS Access macros in your database are causing you problems
now.  I have been able to do some of what you are needing to do with
forms, only I used queries.  Many of my forms have list boxes where I
select one of a list of options to be inserted into a database field.
Although I have not used it, there is another type of drop-down listbox
that presents options, but if an option not in the list is needed, the
user may enter that option into the field.  I may have misread your
posting, but that may be what you need.  I can see that there are times
when macros would be the only answer to a problem, such as with custom
forms, but my recommendation is to avoid them whenever you can.
Girvin Herr


On 05/05/2014 12:28 PM, milica wrote:

 Thanks,

Actually, that base in ms access is kind of start point, and needs to


be



more developed,so I have to learn LO macros anyway :(

   I'm reading the book OpenOffice.org Macros Explained (great book!),


and


making new version in LO but in LO Calc.
Thank you once again :))


On Mon, May 5, 2014 at 7:29 PM, TomD [via Document Foundation Mail


Archive]


<[hidden email] <http://user/SendEmail.jtp?type=node&node=4107732&i=0

 wrote:



Hi :)

Good point!!

An external database is a really good approach.  Many people go for


MySql



or MariaDb (unless using a Mac) but that's owned by Oracle and some



worry



about the future of "free" or "Open Source" under Oracle.  Many go for

faster, lighter java back-ends such as Hsqldb as an external but


others



worry about the whole java issue.


So Postgresql might well be a good choice.  They have put a lot of


work



into building a decent connector for Base.

Regards from
Tom :)







On 5 May 2014 15:44, Wolfgang Keller <[hidden email]<


http://user/SendEmail.jtp?type=node&node=4107696&i=0>>



wrote:


 I'm new user of LO Base, we are transitioning from MS Access, and I

need to redesign our db from it.


One word of advice based on experience:

Avoid use of the "built in" database.

Use a proper client-server RDBMS. Preferrably PostgreSQL, as it's
reliable and the driver comes with LO.

Otherwise you *will* regret it the day your data has gone to
Nirvana.

Sincerely,

Wolfgang

--
To unsubscribe e-mail to: [hidden email]<


http://user/SendEmail.jtp?type=node&node=4107696&i=1>



Problems?


 http://www.libreoffice.org/get-help/mailing-lists/how-to-

unsubscribe/


Posting guidelines + more:



http://wiki.documentfoundation.org/Netiquette



List archive: http://listarchives.libreoffice.org/global/users/

All messages sent to this list will be publicly archived and cannot


be



deleted



 --

To unsubscribe e-mail to: [hidden email]<


http://user/SendEmail.jtp?type=node&node=4107696&i=2>



Problems?

http://www.libreoffice.org/get-help/mailing-lists/how-to-
unsubscribe/
Posting guidelines + more:


http://wiki.documentfoundation.org/Netiquette



List archive: http://listarchives.libreoffice.org/global/users/

All messages sent to this list will be publicly archived and cannot
be
deleted


------------------------------
   If you reply to this email, your message will be added to the


discussion



below:



 http://nabble.documentfoundation.org/Need-help-with-Base-

tp4107400p4107696.html


   To unsubscribe from Need help with Base, click here<

.
NAML<


http://nabble.documentfoundation.org/template/NamlServlet.jtp?

macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&
base=nabble.naml.namespaces.BasicNamespace-nabble.view.
web.template.NabbleNamespace-nabble.view.web.template.
NodeNamespace&breadcrumbs=notify_subscribers%21nabble%
3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_
instant_email%21nabble%3Aemail.naml







--
To unsubscribe e-mail to: [hidden email]<


http://user/SendEmail.jtp?type=node&node=4107732&i=1>


Problems?
http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/
Netiquette
List archive: http://listarchives.libreoffice.org/global/users/
All messages sent to this list will be publicly archived and cannot be
deleted



------------------------------
  If you reply to this email, your message will be added to the
discussion
below:


 http://nabble.documentfoundation.org/Need-help-with-Base-

tp4107400p4107732.html


  To unsubscribe from Need help with Base, click here<


http://nabble.documentfoundation.org/template/NamlServlet.jtp?
macro=unsubscribe_by_code&node=4107400&code=
bWlsamtvdmljLm1pbGljYS44M0BnbWFpbC5jb218NDEwNzQwMHwxODIyNjg3NDEz


.
NAML<


http://nabble.documentfoundation.org/template/NamlServlet.jtp?
macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&
base=nabble.naml.namespaces.BasicNamespace-nabble.view.
web.template.NabbleNamespace-nabble.view.web.template.
NodeNamespace&breadcrumbs=notify_subscribers%21nabble%
3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_
instant_email%21nabble%3Aemail.naml






--
If you can imagine it, you can achieve it; if you can dream it, you can
become it.




--
View this message in context:
http://nabble.documentfoundation.org/Need-help-with-Base-
tp4107400p4107761.html
Sent from the Users mailing list archive at Nabble.com.
--
To unsubscribe e-mail to: users+unsubscribe@global.libreoffice.org
Problems?
http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/
Netiquette
List archive: http://listarchives.libreoffice.org/global/users/
All messages sent to this list will be publicly archived and cannot be
deleted








--
To unsubscribe e-mail to: users+unsubscribe@global.libreoffice.org
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-
unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.libreoffice.org/global/users/
All messages sent to this list will be publicly archived and cannot be
deleted



-- 
To unsubscribe e-mail to: users+unsubscribe@global.libreoffice.org
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.libreoffice.org/global/users/
All messages sent to this list will be publicly archived and cannot be deleted

Context

Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.