trying to get a local server version of Advantage OLE DB Provider to work on a 64 bit Windows 7 machine. installed the 64 bit version 10.00.0.3 release and copied my application. registered the adsoledb64.dll from the app directory. I get nothing. Doesn't write a log either. Am I going to have to compile the app on the 64 bit machine? very confused and frustrated.
Based on the information I have gleaned from the comments, it sounds as if your application is running as a 32-bit application. If so, it will not be able to load 64-bit version of the OLE DB provider. The conn.Open(); call would likely result in an error such as this:
The 'Advantage.OLEDB.1' provider is not registered on the local machine.
One way to test this would be to install the 32-bit version of the provider to see if it works.
Alternatively, you might consider using the Advantage .NET Data Provider rather than the OLE DB provider. Using a native data provider instead of going through OLE DB might prove simpler in the long run.
Related
Suppose I have Rails 4 app, call it "Super SaaS". Now my client says he likes my appvery much, but he doesn't want his data to be in the cloud. So he says he would buy a licience from me to deploy "Super SaaS" on his own server. More like Atlassian Jira.
The question is: is there any secure way(in terms of protecting source code) to do that?
While you can probably package up your code as a JRuby application with JAR files and Java byte code, there are decompilers for that, so you can never presume your source to be 100% secure.
Ideally you'd offer some sort of VM appliance that the customer can install, a system image compatible with VMWare or whatever virtualization system they're using. This helps package up a fairly secure environment, but won't protect against a determined adversary trying to get your source code.
If you're giving out your code to someone in any form, compiled or otherwise, you have to have a certain amount of trust. Even compiled executables are not immune to reverse-engineering.
Back in the days of Delphi 7, remote debugging was mostly ok. You set up a TCP/IP connection, tweaked a few things in the linker and you could (just about) step through code running on another PC whilst keeping your Delphi IDE and its libraries on your development PC.
Today, with Delphi XE2,3,4 you have paserver which, at least at the moment can be flaky and slow. It is essential for iOS (cross platform) development, but here at Applied Relay Testing we often have to debug on embedded PC's that run recent Windows. To do this we have employed a number of strategies but the hardest situation of all is to visit a customer site and wish that one could 'drop in' a Delphi IDE + libraries and roll up ones sleeves to step through and set breakpoints in source code.
It is quite likely - hopefully - that the paserver remote debugging workflow and its incarnations will improve over time but for now I got to wondering how it might be possible to install Delphi + libraries + our source code on a USB key so that with only a minimal, perhaps automated setup, one could plug that key into a PC and be compiling, running and debugging fairly quickly.
I can see that the registry is one of the possible issues however I do remember that Embarcadero once talked about being able to run their apps from a USB key. Knowing how much of a pain it is to install my 20-odd libraries into Delphi though, it is not trivial and needs thinking about.
Has anyone done anything like this or have any ideas of how it might be done?
Delphi does not support what you are asking for. But what you could do is create a virtual machine with your OS, IDE, libraries etc installed in it, then copy the VM onto a USB drive, install the VM software on the customer system, and run your VM as-is. There are plenty of VM systems to choose from.
First, I need to get this out of the way: embedded PCs running Windows?? Sob.
Ok, now for a suggestion: if a full virtual machine isn't an option for this task, application-level virtualization may be. This intercepts registry calls and other application-level information and maps them to a local copy, allowing essentially any application to be turned into a portable version. The good news is that there are free versions of several programs that can turn Windows programs into virtualized apps.
The only one I've personally used is MojoPac, and found it delivered as promised although was very slow running off of a (old, very slow) flash drive.
http://lifehacker.com/309233/make-any-application-portable-with-mojopac-freedom
I haven't used this newer "freedom" version though.
Two other programs I've seen that appear to be popular are Cameyo:
http://www.techsupportalert.com/content/create-your-own-portable-virtual-version-any-windows-program.htm
and P-Apps,
http://dottech.org/26404/create-a-portable-version-of-any-software-with-p-apps/
but I can't vouch for the quality of either of these two.
Hope this helps.
I have a friend who has a management application, and he would like to import some of his data in Excel.
The thing is I have no idea about how to read this type of files,
In his application directory he has a folder named app.dbs. Inside there are *.idx and *.dat files.
What would be the easiest way to read this files? Maybe ODBC connector, or installing some version of Informix DB??
That sounds like C-ISAM files, or an Informix-SE (Standard Engine) install. You most certainly can't read them directly. Googling Informix C-ISAM files ODBC generates plenty of results. Also this page explains the relationship between the two.
I've never used SE, but assuming its installation is reasonably similar to its big brother Informix Dynamic Server (and I believe it is), have a look on your friend's computer for an 'Informix' directory. You may find an %INFORMIXDIR% environment variable to point you in the right direction. Within that, look for an executable in its subdirectory bin called dbaccess.exe. Run that from a DOS prompt and you should hopefully get an SQL interpreter that allows you to read and extract the data.
If you have no luck finding such a directory, then it's more than likely the "management application" is writing C-ISAM directly, and you'll need an ODBC driver for C-ISAM, as you surmised.
The name app.dbs containing the .dat and .idx files is an almost sure indication that you have an Informix SE (Standard Engine) database (someone might have faked it, but it is pretty improbable).
Given that you may be able to use an Informix ODBC driver and SE itself to access the database, or you may be able to use an ISAM-based ODBC driver to access the database. It depends in part on whether this is a one-time migration or an ongoing access while the application continues to work on the database.
Assuming all of this is installed on Windows, you should indeed find a %INFORMIXDIR% directory, which will have a dbaccess.exe in the bin sub-directory, and an sqlexec.exe either in the bin directory or in the lib directory (it would be in $INFORMIXDIR/lib on Unix; I'm not sure about Windows). These should be able to access the database. If you find sqlexec but not dbaccess, then you've got a seriously old version (more than 20 years old, but I know of other people still using such archaic versions). You should be able to identify the version by running dbaccess -V or sqlexec -V. If it is 7.25, it is reasonably recent (that's been current for a decade or more); if it is older than that, it is verging on the archaic.
I am creating an application of opencv gpu in visual studio 2008.The application is win32 application and the operating system is Windows 7 64 Bit.The application is being build successfully but when I am trying to run the program the program is getting crashed.The error message shown is "The application is unable to start".
Please suggest me. I used the dependency walker and it seems that the application is trying to call 64 bit dll of windows.
How to get over with this problem?
The Dependency Walker displays confusing information for a 32 bit app if you are running the 64 bit version of depends.exe. I don't think it really understands the WoW (Windows on Windows) system. Also, I think that any attempt to link to 64 bit libraries would be caught at compile time. Most likely, your app is just not finding all the required DLLs. The Event Viewer should have more information about what the error was. Go to Windows Logs | Application. Use the log filtering if it's hard to find the entries for your app.
I just got a new laptop with Windows 7 (32-bit) and I have to install the following things:
SQL Server 2005 (Dev edition)
SQL Server 2008 (Dev edition)
Visual Studio 2008 Prof.
Delphi 2007
Delphi 2010
In addition I need the usual suspects such as Office 2007 etc.
I was thinking of doing it in the order listed above but would like to know if this is the best way.
On my old system I must have done something wrong as I have had lots of problems with broken help files etc. especially in Delphi.
Thanks.
IMHO: You shouldn't!
Instead, install each development enviroment on different virtual machines.
(Eg VMware Workstation)
The disadvantages are minimal. Perhaps some more costs (VMware + additional OS license).
But the advantages are invaluable!
Portability. If you get a new (physical) machine, it is very simple to copy the virtual machines from the old one to the new one. (You can even save the vm's on a USB-stick and run them on different computers).
Snapshots. Before you do any changes in your dev.env. (updating, adding and removing sw) you can take a snapshot of the vm, and roll back to this state at any time! Make sure you've got your documents and source code on the host machine or a server, though. Because everything is rolled back. Every file is restored to the state it had at the time the snapshot were taken.
Forks/branching. If you are working on a new feature, you can create a branch of the dev.env. (via snapshots), and easily switch between the experimantal dev.env and the production dev.env. at any time.
Using snapshots you can maintain multiple (virtual) operating systems without having to buy several OS-licenses. (You can't run these branches of the OS simultaneously, of course).
More testing environments on the same (physical) machine. Different combinations of OS-versions and MS Office-versions etc)
Protection when testing risky code. (Eg deleting files, updating databases, registry changes etc)
Start playing with new sw-versions without messing up the existing dev.env.
Separate customers/projects according to their various needs for different third party tools, database solutions, report solutions etc
I installed Delphi 2010 after Delphi 2007 without any problems.
Just uninstalling gave me some problems (BDE had to be installed again).
My main suggestion would be to download the latest ISO for Delphi 2007 and Delphi 2010.
Don't rely on your installation DVD's if they aren't current. I used to have problems installing Delphi 2007...I bought my copy around the first month it was available...then I downloaded the latest ISO with all the updates and never had problems on Windows 7 Enterprise (32-bit).