Hi :) Hmmm, actually i've only just realised that a 2nd grab from the 'proprietary' back-end data-tables might not be such a nightmare. Just keep a copy of the current export as it is so that the new grab can be compared against it. Any differences could then be added to the data-tables held fairly locally. Hopefully it's unlikely that different updates would happen to a single old field both here and there!
Anyway, i guess my main question is could Base be used as the front-end for data tables (the back-end) that is online? Regards from Tom :) On 16 January 2014 10:32, Tom Davies <tomc...@gmail.com> wrote: > Hi :) > Thanks :) I guess that is part of my question. The original back-end > of the database in this case is MySql/MariaDb. Base can normally use > MySql/MariaDb as it's own back-end so there would seem to be 2 > different routes that might be worth considering; > > 1. Attach Base directly to the existing MySql/MariaDb that is hosted > on some web-site (or at least on an internet-facing server such as a > Cloud). I know the back-end can either be on a local machine or on a > local-area-network but could it work over the internet too? > > 2. Since the exported data is already laid out for MySql/MariaDb then > just install MySql or MariaDb locally (onto the same desktop machine > that is using Base) or onto a LAN file-share so that all machines can > use Base (or other front-ends) to access the data. This seems to be > the route Alex is suggesting except he goes further and suggests using > a fairly local machine that already has MySql installed and just > adding the exports as a new file on that machine. > > > Carl, the o.p., seems to be thinking about the 3rd route and walking > headlong into the type of troubles Jay just outlined. As i see it the > problem with the 2nd or 3rd routes is that exporting data gives static > data. As time goes on the original database gets updated with new > data. So maybe at some point a new export might need to be grabbed > and then somehow figure out a way to merge the updated data at this > end with the updated data from over there. New records/rows are > tricky enough but tracking changes in fields/columns in individual > ancient records would be a complete nightmare. If it's a case of a > single snapshot to rescue data from a sinking Cloud then none of that > is a worry and the single export routes are perfect > > So it's really route 1 that i'm curious about and really in a yes/no > way rather than in any detail. Carl doesn't seem to be thinking along > those lines so this is a bit of a tangent that will probably crop up > again in a future thread and be more relevant then. > > Regards from > Tom :) > > > > On 16 January 2014 01:57, Jay Lozier <jsloz...@gmail.com> wrote: >> Tom, >> >> The initial format and some of the data types would need to be converted so >> the syntax matched to the new . This is a well known problem when migrating >> from one SQL database to another where there are added, non-standard data >> types. >> >> Jay >> >> >> On 01/15/2014 05:12 PM, Tom Davies wrote: >>> >>> Hi :) >>> Is it likely to be possible to connect Base directly to the original >>> data? So that instead of getting an export or a dump of the data it >>> can be read dynamically? >>> >>> I know it is not what the o.p. is asking for but i often wonder. >>> Regards from >>> Tom :) >>> >>> On 15 January 2014 22:03, Alex Thurgood <alex.thurg...@gmail.com> wrote: >>>> >>>> Le 15/01/2014 22:08, Carl Paulsen a écrit : >>>> >>>> Hi Carl, >>>> >>>>> ) ENGINE=MyISAM DEFAULT CHARSET=latin1; >>>> >>>> This is enough to tell us that the data came from a mysql database >>>> originally. MyISAM is the default engine for non-transactional MySQL >>>> databases : >>>> >>>> http://en.wikipedia.org/wiki/MyISAM >>>> >>>> In the sample table you give, the table/field definitions are particular >>>> to mysql, so if you try to run that sql with another db engine, e.g. in >>>> hsqldb via LO Tools > SQL, it will fail because it will not recognise >>>> the field types you're trying to create (e.g. enum, mediumint. >>>> >>>> So, your best bet would be to import that into a mysql server, assuming >>>> you have one to hand and you have some kind of console/terminal access >>>> (localhost / same machine): >>>> >>>> mysql < '/path/to/myfiletoimport.sql' >>>> >>>> optionally with -p if you require authentication for the user that is >>>> connecting to the mysql server : >>>> >>>> mysql -p < '/path/to/myfileimport.sql' >>>> >>>> There are many web sites on the internet that are full of information on >>>> how to set up and import data into a mysql server. >>>> >>>> >>>> Alex >>>> >>>> >>>> -- >>>> To unsubscribe e-mail to: users+unsubscr...@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 >>>> >> >> -- >> Jay Lozier >> jsloz...@gmail.com >> >> >> >> -- >> To unsubscribe e-mail to: users+unsubscr...@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+unsubscr...@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
