Login ProductsSalesSupportDownloadsAbout |
Home » Technical Support » ElevateDB Technical Support » Support Forums » ElevateDB General » View Thread |
Messages 1 to 9 of 9 total |
Retrieving some tables for debugging. |
Wed, Jan 30 2013 1:16 AM | Permanent Link |
Adam H. | Hi, In some of my applications, I have had the need to transfer some of the data from a clients to my own computer for debugging. (Truth be told, this happens on almost a weekly basis for some of my clients). As some of these applications have databases that exceed into Gigabytes of space, transferring all the datafiles isn't really an option. As such, I normally only transfer just the tables I need to debug instead of the entire data. I'm aware recently that this could pose a problem in EDB if the structure of the catalog is different on my working PC as compared to that of my end user. Am I right / safe in assuming that providing the catalog is the same for my end user as myself, that a simple copying of the tables I need to my computer over the existing tables is all I need to accomplish this task, or am I looking for trouble? Also - in Version 3 I've heard rumors that it may become a single file database. Will we have the option for either/or, or will version 3 limit me to having to copy the entire database everytime I want to do some debugging (unless I write procedures to export some files to csv, and import them my end)? Cheers Adam. |
Wed, Jan 30 2013 3:33 AM | Permanent Link |
Roy Lambert NLH Associates Team Elevate | Adam
>Am I right / safe in assuming that providing the catalog is the same for >my end user as myself, that a simple copying of the tables I need to my >computer over the existing tables is all I need to accomplish this task, >or am I looking for trouble? Theoretically you are correct, however, if you don't need the data in the other tables get them to send just the tables you want and their catalog. ElevateDB will create empty tables on disk for the missing ones and you can then be sure of a match. Can't answer on V3 Roy Lambert [Team Elevate] |
Wed, Jan 30 2013 10:25 AM | Permanent Link |
Adam Brett Orixa Systems | Adam H.
A couple of other things to consider: 1. Use of the EXPORT TABLE SQL statement in EDB, which allows single tables to be exported as files which can then be re-imported. If the exported files are saved to a shared STORE both the export and import processes can be automated with an EDB Procedure / Job. 2. Use of PUBLISH: Publish the clients database, but only publish those tables you want to compare/work with. Periodically run a job on the client to: * Save updates. * Copy the update file from a store on their computer to some store you can access easily. Have a job on your computer to Load Updates from this update file. All that will get passed around are the updates for those tables you are comparing, so the file size is minimized. You can also set Compression-levels for the update files ... to further minimize data traffic. Either way EDB can automate the whole process removing a lot of the legwork. |
Wed, Jan 30 2013 4:44 PM | Permanent Link |
Adam H. | Hi Roy,
> Theoretically you are correct, however, if you don't need the data in the other tables get them to send just the tables you want and their catalog. ElevateDB will create empty tables on disk for the missing ones and you can then be sure of a match. > > Can't answer on V3 Good call regarding the catalog Roy! Something for to keep in mind. I do like the idea that it will automatically create tables that don't exist. Cheers! Adam. |
Wed, Jan 30 2013 4:45 PM | Permanent Link |
Adam H. | Hi Adam...
> A couple of other things to consider: > > 1. Use of the EXPORT TABLE SQL statement in EDB, which allows single tables to be exported as files which can then be re-imported. If the exported files are saved to a shared STORE both the export and import processes can be automated with an EDB Procedure / Job. > > 2. Use of PUBLISH: > > Publish the clients database, but only publish those tables you want to compare/work with. > Periodically run a job on the client to: > > * Save updates. > * Copy the update file from a store on their computer to some store you can access easily. > > Have a job on your computer to Load Updates from this update file. > > All that will get passed around are the updates for those tables you are comparing, so the file size is minimized. You can also set Compression-levels for the update files ... to further minimize data traffic. > > Either way EDB can automate the whole process removing a lot of the legwork. Thanks for those ideas. Exporting the table and importing could be a good option. Not quite as simple as a copy/paste - but doable. As for PUBLISH - I may need to make myself familiar with the PUBLISH feature that you've mentioned Adam. Not something I've come across or used yet. Cheers for that Adam. |
Thu, Jan 31 2013 7:35 AM | Permanent Link |
Roy Lambert NLH Associates Team Elevate | Adam
>As for PUBLISH - I may need to make myself familiar with the PUBLISH >feature that you've mentioned Adam. Not something I've come across or >used yet. PUBLISH is a great feature mainly intended to support database replication. I don't think it will be of use in the scenario you described since its unlikely that you want to continuously keep your database synced to your customers. Roy Lambert [Team Elevate] |
Thu, Jan 31 2013 8:54 AM | Permanent Link |
Adam Brett Orixa Systems | >>PUBLISH is a great feature mainly intended to support database replication.
Yes, but it is also brilliant to hack with, as it creates UPDATE files which you can use in a wide variety of ways. >>I don't think it will be of use in the scenario you described since its unlikely that you want to continuously keep your >>database synced to your customers. I think Adam could use it for roughly what he needs with a bit of tweeking ... particularly limiting the range of tables for which updates are loaded / saved by using the PUBLISH TABLES keyword. Just an idea. |
Thu, Jan 31 2013 4:31 PM | Permanent Link |
Adam H. | Hi Gentlemen,
Thanks for the info. Publish... while it may not be designed for what I want, it looks like it could come in very handy for some other operations at a later date! Thanks very much. Cheers Adam. |
Fri, Feb 1 2013 12:52 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | Adam,
<< Am I right / safe in assuming that providing the catalog is the same for my end user as myself, that a simple copying of the tables I need to my computer over the existing tables is all I need to accomplish this task, or am I looking for trouble? >> Yes, that will be safe as long as the basic structure of the tables are the same (at least for the tables that you're interested in, they don't all have to match, just the ones that you want to open and look at the data). << Also - in Version 3 I've heard rumors that it may become a single file database. Will we have the option for either/or, or will version 3 limit me to having to copy the entire database everytime I want to do some debugging (unless I write procedures to export some files to csv, and import them my end)? >> Being single file, there's no way to just separate out certain bits, so yes, you'll have to always copy the entire database. If you have any other questions, please let me know. Tim Young Elevate Software www.elevatesoft.com |
This web page was last updated on Saturday, April 27, 2024 at 08:52 PM | Privacy PolicySite Map © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? E-mail us at info@elevatesoft.com |