Assuming bad-case scenario of a QuickBooks backup that is X years out of date (this is not about the merits of backing up).
Is it possible to merge a current, up-to-date, QuickBooks 2013 database with the backup to restore lost data?
The situation is that we have a 2013 backup of a database we have been managing since 1996. We recently re-typed an Account from Bank to Expense, which removed the Check Number from all of the Account Transactions. After discovering the error, we re-typed the Account to a Bank account, however, we lost all Check Numbers for the history of the database.
The 2013 backup contains all Check numbers from 1996 to 2013, and we can easily manually reconcile the Transactions from 2013 to today.
Is it possible to take the 2013 backup, and fast-forward to, or merge it with, the current head of the current Database?
I have heard mumblings of editing an Export in Excel, which is fine for this kind of task, but I would not know where to begin to look to do this.
The theory is: If we can take the current Database, and resolve (perhaps by Transaction ID) check numbers from the 2013 backup, and then import this "updated" database, we would pretty much be all set.
I understand that it may not be "that" easy, but if there is a way to get access to look at this data, I am sure I would be able to figure something out.
And then, there is making regular backups...
There's not a great way to import Excel data built into QuickBooks, so your best bet would be to use a third party utility to export/import the data. I would recommend the Data Transfer Utility application, as it's designed to do exactly what you are looking for (http://marketplace.intuit.com/appid-2309-overview.aspx)
You'll need to restore the old database into it's own separate file, which when you restore, just give the restored file a new name.
Related
The idea is to have git or a git-like system (users, revision tracking, branches, forks, etc) store the 'master copy' of objects and relationships.
Since the master copy is on the filesystem, any changes can be checked in, tracked, and backed up. Neo4j could then import the files and serve queries. This also gives freedom since node and connection files can be imported to any other database.
Changes in Neo4j can be written to these files as part of the query
Nodes and connections can be added by other means (like copying from a seed dataset)
Nodes and connections are rarely created/updated/deleted by users
Most of the usage is where Neo4j shines: querying
Due to these two, the performance penalty on importing can be safely ignored
What's the best way to set this up?
If this isn't wise; how come?
It's possible to do that, but it will be lot of work which would not have a real value. IMHO.
With unmanaged extension for Transaction Event API you are able to store information about each transaction onto disk in your common file format.
Here is the some information about Transaction Event API - http://graphaware.com/neo4j/transactions/2014/07/11/neo4j-transaction-event-api.html
Could you please tell us more about the use case and how would design that system?
In general nothing keeps you from just keeping neo4j database files around (zipped).
Otherwise I would probably use a format which can be quickly exported / imported and diffed too.
So very probably csv files with node-file per label ordered by a sensible key
And then relationship-files between pairs of nodes, with neo4j-import you can recover that data quickly into a graph again.
If you want to write changes to the files you have to make sure they are replayable (appends + updates + deletes) , i.e. you have to chose a format which is more or less a transaction-log (which Neo4j already has).
If you want to do it yourself the TransactionHandler is what you want to look at. Alternatively you could dump the full database to a snapshot at times you request.
There are plans to add point-in-time recovery on the existing tx-logs, which I think would also address your question.
I have a little bit of logs [ 200Mbytes/per day ]. What I want is to use certain data from this logs to build some statistics and show it through web interface. After pre-processing these files I get 4-5 files like this one:
hadooper#ubuntu:/usr/local/hadoop$ du -h part-r-00000
4.0K part-r-00000
hadooper#ubuntu:/usr/local/hadoop$ cat part-r-00000
201508042015 444335775
201508042020 563
201508042025 320787123
.....
I'm planning to store all this at least for year, maybe even more. Not sure yet.
My question is where would be better to store and retrieve data: files or database ?
I'm planning to use rails as backend. And as for now it seems like storing everything in files are ok option. But there might be some drawbacks in long term which I'm not aware of right now.
I'm sure there are a lot of experienced people who solved similar tasks. Would much appreciate your thoughts and help
If you are only trying to store the files, store as flat/zipped file or add to the database and then export them as backup file from the database. Preparing backup from database will ensure easier import later when you need the data.
If you will need to perform queries on them too all this time, store them in database as querying to database is faster (because of indices) and easier (because of availability of DDL, DML etc.)
If you are worried about security, encrypt your files or encrypt the database and then export.
Let me know if there is some case I forgot to address.
I need to define a large amount of data to be stored within an app and used as a lookup table. For instance, I have an array of manufacturer names, each with a mfg code. Each manufacturer can make different products, each with their own code as well.
A,7 could be deciphered to mean
Manufacturer: Apple(A)
Product: MacMini(7)
I see several ways of defining this, but I'm not sure which would be best.
Option 1) #define these constants in a separate header file such as:
#define MFG_APPLE #"A"
#define MFG_DELL #"B"
#define PRODUCT_MAC_MINI 7
#define PRODUCT_INSPIRON 2
Option 2) create a dictionary object filled with dictionary objects to allow me to index through them easier.
Option 3) use core data to create a database of these mfgs and products and relationships.
If option 2 or 3 is suggested, are there easy ways to pre-populate these data structures instead of hard-coding them to populate during program startup?
Option 4) Create a web service to tie this back to a server, where the data can be updated more often. A JSON query will send the mfg and product codes to the server, where it can respond with the mfg and product names.
You should consider the following: If the database is shipped with the app, you will have to release an update for the app each time the database must be updated. So the question is, how frequently will you have to update the data? If it's fine to update the database once every couple of months or maybe just once a year, shipping the database with your app might be an option, if you need to update it every month or even weekly, you should definitely host the database somewhere on the web; releasing an update in such short intervals is not a feasible option.
Another thing you should consider: If the database exists solely as a web service and each look up requires a JSON call to the server, it won't be possible to perform a lookup if the user is offline (currently has no network access for whatever reason). Also each lookup costs the user traffic, so if the user has a monthly limit, yet needs to perform plenty of lookups a day, using your app may quickly cause him to exceed that monthly limit, leaving him without any Internet service (or a very throttled one) in the end.
From my experience, it is best to host such a database online, yet cache it for offline access if possible. The app itself ships with a database copy, that was up-to-date the day you built the app for distribution. Each time the app is started, and maybe once a day in case the app is never quit, it will query a web server for the current "version" of the database. If this version is newer than the one shipped with the app, it tries to downloads a copy of this database to its local cache and then switches to the cached copy for future lookups. If the cached copy gets lost (caches may be flushed by the system at any time), it will have to re-download it. In the meantime, it can use the shipped database, which is outdated, yet better than nothing. If download is not possible (e.g. not enough free space is available on the device), the app may want to make online queries directly if the user currently is online, fall back to the out-dated shipped database if he is offline, and retry to download a cache copy at some later time (maybe the device will have more free space available at that time).
So basically your app will have a work flow as follows:
START
A locally cached copy exists? If NO Goto 6.
The locally cached copy is up-to-date? If NO Goto 5.
Perform the lookup using the local cached copy. Goto 12.
Delete the outdated cached copy. Goto 1.
The shipped database is up-to-date? If NO Goto 8.
Perform the lookup using the shipped database. Goto 12.
Download the updated database.
Download succeeded? If YES Goto 4.
The user is currently online? If NO Goto 7.
Perform the lookup using a JSON webservice. Goto 12.
END
If you only add more entries to the database in the future, yet existing entries will never change, there is also another, even much better option: You have simply two databases. One that ships with the app and one that only contains the updates (new entries added) after the last app release. This shrinks the amount of data that needs to be downloaded and cached dramatically. In that case your app must always perform two lookups, one in the shipped database (which is always performed first), and if nothing is found there, in the downloaded cached copy, which does not contain the entries already found in the shipped database (or directly online, if no cached copy is available, yet the user currently has Internet access). Each time you release a new update of the app, it will get a new full copy of the database, hence you can reset the update database back to zero entries and only keep adding new entries there (or you can keep different update databases lying around on the server for different app versions that had different databases shipped with them, if you don't think that is too much hassle to manage).
The update database for download may even be created dynamically by the server, that would of course be the best option. E.g. after shipping the app, you add 3 vendors and 30 products to the database, and every vendor and product has a unique ID (that is strictly increasing with each new entry added), then the app can tell the server that the highest vendor it knows has ID X and the highest product has ID Y, in which case the server sends out an update database with all vendors and products whose IDs are higher than X and Y.
All these decisions influence on the database format to use. Generally it sounds a lot like a job for CoreData, yet if you want dynamic update databases, the updates should be delivered in a different format (JSON, XML, CVS, or something else a server can easily generate) and be converted to CoreData by the app after the download is completed, since dynamically generating CoreData databases on a server is rather hard and definitely not recommend.
How can I make a 30-day trial for my application? I need to allow users to use an application only 30 days. How to count these days?
I keep the first and the last date in registry. But if to change a system time - no protection will be. I need to count these 30 days.
You could probably come up with a system that requires an internet connection, but without something that the user can't tamper with, I don't see a solution.
Any solutions that rely on an untrusted element (an element of the protection that is under the user's control) is critically weak.
The simplest way I can think of to protect against the user moving the clock back is to limit the total number of launches.
However, attempts to limit the number of launches requires persistence -- saving data to the disk, perhaps encrypting and storing a modified version of your activation data file -
Imagine that you count one of the 30 days as "used up" once the app has been launched, on a unique occasion, even when the same date is re-used. In order to avoid using up more than 1 "activation time day" when launched, the user must allow your software to re-save its activation file each time it runs.
To block that approach, the user needs only to keep the apparent date from changing, plus they must either prevent you from storing anything to disk; or they can simply track and record your changes and reverse them out, either using a monitoring process, or using VMWare snapshots. About VMWare snapshots, you can do nothing. The virtual machine's disk is not under your control.
You can protect your app of users setting the clock back simply by storing in the registry the date of last execution.
Each time the app is started you need to do the following:
Check current date (as reported by the system clock) against the stored last execution date and, if current date is earlier than the last execution one, consider that the trial period has expired (or whatever you prefer).
If the previous check is ok, save the current date in the registry and continue execution.
As WarrenP says, any technique storing information locally can be easily circumvented using VMware snapshots.
And anyone, including those who check via internet, can be skipped via assembler level hacking.
Here's a discussion on Shareware trial enforcement with Delphi:
Best Shareware lock for Delphi Win32
Along with discussions on various 3rd-party solutions, techniques for DIY, etc..
IMO, DIY is feasible if your app produces data that the user will want to keep around, then you can simply embed a copy of the usage/day counter in the database in such a way that they can't wipe it without destroying their data. I also like watermarking (printing "trial" on reports, etc..), escalating nag severity, but I do not recommend or condone "drop-dead" crippling until WAY past the expiration data. I also like to measure "days of actual use", instead of using a calendar.
Registry manipulation works, and many of the 3rd-party protectors use it. But you need to be stealthy, and keep backups in several locations simultaneously.
You should also consider having separate trial and registered versions. But also consider that pirates will buy the registered version with a stolen card, and put it on Rapidshare, BitTorrent, etc..
Also note that elaborate defenses lead to support headaches. Sometimes PCs crash and the clock gets set backwards. They install new harware. PCs get rebuilt, restored from backup, etc.. If a user is running a debugger, he may be a software developer, not a pirate. If your app looks like it has been patched, it may be an overly-aggressive antivirus. And at any time, a shoddy patch for Windows may cause your program to think that it's being attacked, hacked, or reverse-engineered. You have been warned...
Encrypt a date and store it in registry the best way to do it is that date to be stored by the installer itself and if the date doesn't exist the application should quit.
There is an open source project (which was a commercial product before):
TurboPower OnGuard is a library to create demo versions of your Borland Delphi & C++Builder applications. Create demo versions that are time-limited, feature-limited, limited to a certain number of uses, or limited to a certain # of concurrent network users.
I have not checked which Delphi versions are supported.
For this kind of "protection" and some others, I have used TmxProtector (open source) from MaxComponents in the past with good results. From the link provided:
The TmxProtector is a software protection component. It was designed
for quick implementation of application protection functions. You can
create time-trial and password protected applications. You can set the
maximum number of execution, and it can work with registration keys as
well.
This compoment uses very simple encryption to store the expiration date in the registry and it provides some simple detection for tampering on the system date.
It sounds like you need to store the date the last registry entry was written. Then inside your program, test if the current date is less than the date last registry entry was made. If true display a message that the trial period has expired and the program must be purchased.
Here are some ideas on how to deal with clock changes during the trial period:
Save both the date of first and the date of the last program start. If the date of the last program start is greater than the current date, then the user has moved the clock back. I simply increase a day and save the new date as the date of last start. You can of course decide to just end the trial.
To try to defeat trial bypass programs (RunAsDate for example) which run your application by setting the date and time to a specific value, you can instead of getting the date via the usual Delphi way (Date, Now), get, for example, the last modification date of NTUSER.DAT.
Save your trial data on two separate locations, either two registry locations, or file and registry. This way even if the user deletes one of the trial data locations, you'll still have a backup one to use.
If you keep your trial info in registry, the registry could be deleted by the user. Evey one expects to find the registration info there.
There is one place where the user might not think to look into: your own app (EXE file). Put an ANSI string constant (MUST by ansi/ascii or other 1 byte string, static array, etc) into your program, like 'xyxyxyxyxyxy'. Compile your app. Open your complied app with a hex editor. Search for that string. Now your program could use that area to store the trial info into itself.
Use this method in conjunction with others: store your info in registry also, on disk, etc.
Anyway, the best would be to get the registration info from your server.
The big drawback: 1. The server must be ALWAYS online! 2. The user must be connected to internet (when it uses your app).
Also use a Delphi license management library to help you encrypt the license info and generate a string-based key that you can send to your customers upon registration.
Anyway, whatever you send to your server needs to be based on the hardware fingerprint of that computer. Otherwise your license key will leak out on some warez website and everyone will be able to use that key. But if the key is hardware-based it would be useless if it is leaked on Internet.
Just remember: don't over do it! There is no such thing as unbreakable software protection. Microsoft could not do it!
As the thread pointed to mentioned, I encourage you to look into WinLicense: http://www.oreans.com.
I've been using it for quite some time and it handles trial periods quite well. It also handles licensing, customer lists, etc.
Tom
I'm looking to add a 14-Day trial limit to my software. The program has been written in Delphi 7.
Any help would be much appreciated.
You could try Turbopower OnGuard. This is now opensource.
http://sourceforge.net/projects/tponguard/
There are several tricks you can use, but none of them 100% fail save.
You can use some kind of licensing mechanism.
You can store the setup time somewhere hidden in the registry.
You can store the setup time in a file (possibly an executable file or dll).
You can store the IP address in a central database and check each time if the 14 days are passed (you need a internet connection for that).
You can create a file (for example a dll) dynamically on your server and have the installer retreive that file. (Be sure to log the IP so a second attempt will not be possible).
But I think the best way, is to give trial versions with limited functionality. For example: No printing, no save of project, or only small projects can be saved.
That way you avoid the hassle and possible clients can take the time to evaluate your project.
EDIT: If you build a mechanism to check against roling back the clock. Be sure to build in a margin, else the program will be locked if you travel back to an other timezone. Or put the clock back in wintertime. I think a margin of 25 hour will cover everything. (And to be at the save side, you can build in a limit else, the user can roll back the time each day.).
But the best way to keep paying customers, is giving good support. I discontinue products if the service is bad.
One of the things you need to guard against with a time-limited application is users' rolling their calendar back so the application still works. One way around this is to store in your hidden registry place (or wherever) a timestamp whenever the application is started up. If the current date/time is ever earlier than the last timestamp recorded by your app, that means the user has rolled the calendar back and you should disable the application.
Time-limitation is a real pain, though, both for the programmer and the user. It's also not a great marketing idea: why go to the trouble of distributing promotional material (which is what your trial version is) that has an expiration date? It would be like a company mailing out advertisements on paper designed to disintegrate after two weeks.
If your trial version is functionally crippled instead, you might still get sales out of it even months or years later.
You can find the similar question here.
On general note i find time restriction much more useful than functionality restriction. As i explained in the comment to Gamecat post
something to be aware of when performing any of these checks. That the date is never GREATER than 14 days from the date you entered in either direction. A common method around most of these types of limits is to set the date a few years in advance, install and run your software, then set the date back to the current time. If you are hard coded to die 14 days from the original start date, then the user has a few years to try your software. Checking the other direction also gives the user at most 28 days.
I have used Armadillo, Asprotect and Winlicense. Both Armadillo and Asprotect have had serious problems, such as being considered viruses/trojans by some AVs, incompatibility problems, etc.
I haven't used Winlicense enough to have much of an opinion, but support is pretty great.
Obviously both are more complete solutions than what you are asking for - they include protection, licensing, keys, etc.
As mentioned by others, sometimes limiting a feature or adding a watermark is the best option. I've added a watermark to one of my programs (STGThumb) and sales went up about 400%...
I would recommend making a trial serial number with timestamp and force user to enter it into software when its installed. You can even automate it by calling server side page after setup is done.
Timestamp in trial serial key allows you to extend their trial if needed.
In addition you can count backwards to avoid user from changing year when installing:
e.g. if you have 14 days trial generated at 15.11.2008 (server time), you can check that locate date must be greater than 1.11.2008 or less than 24.11.2008 always when serial is used or entered.
You can use a professional tool as SoftwareShield.
I use it in our apps and it provides several licence's models, including timelimited demo.
I created my own key generater (separate program for creating keys). The key values are stored in a binary file with the same name as my program, just a different ext. Example: myprogram.key
I store:
Name
Email
RegType (REG, TRIAL)
RegDate
FirstRun (0 OR 1)
The program looks for the file. If it is not there, it throws a message to the user and closes. The key file generator writes the values in encrypted strings which are then written using the built in stream routines.
I create a TRIAL Key that i distribute with the program. If someone registers, i then create them an official REG key.
Anway, if they are running my program, it first looks for the key file. if found, it checks the reg type, if its a regitered version, then the program loads, and the registration info is displayed. I also store a regdate, which i compare with the day the program runs and - if the regdate is greater than or equal to todays date, the user get sprompted to re-register.
If it finds that the key file stores a RegType of TRIAL, then the date they first ran it is stored in the keyfile, and the flag first run is set to 1. They can then use it for 14 days. Each time they run the program, the date stored is compared with the running date.
Very simple process to write. Is it fool proof? NO, nothing is! I have had great success with my app. Its not wide known, so there are no hackers lookijng to hack it.
The best would be to get the registration info from your server.
The big drawback: 1. The server must be ALWAYS online! 2. The user must be connected to internet (when it uses your app).
To get you started you can use a Delphi license management library to help you encrypt the license info and generate a string-based key that you can send to your customers upon registration. There are quite few libraries out there.
Anyway, whatever you send to your server needs to be based on the hardware fingerprint of that computer. Otherwise your license key will leak out on some warez website and everyone will be able to use that key. But if the key is hardware-based it would be useless if it is leaked on Internet.
And don't over do it! There is no such thing as unbreakable software protection. If Microsoft could not do it, you will not do it. Concentrate on adding nice features to your app instead of creating a bullet proof protection system (which is not possible).