A.M. Hoornweg

Has any of you tried using Bluestacks instead? It's an all-in-one Android emulator which emulates an ARM processor. I'm not using it for development but rather for running some Android apps that aren't available on Windows.

Hello all, Are there any FB experts here? I could use a little help ... I need to enlarge the size of a Varchar primary key column in a small but populated Firebird table from 25 to 40 characters. Much to my surprise, that isn't trivial at all. There are no foreign keys in other tables pointing to this primary key so really, it should be straightforward, shouldn't it? The table name is "channels" and the primary key column is "paramname", it was originally declared as "varchar(25) character set iso8859_1 not null primary key". So far my trial steps were: (note that I did a commit after each statement) //1-Create a temporary column to hold the original data ALTER TABLE channels add temp_paramname VARCHAR(40) CHARACTER SET ISO8859_1 //2-Copy the data UPDATE channels set temp_paramname=paramname //3-Delete the old column ALTER TABLE channels DROP paramname // 4-Re-create column "paramname". The table has records, so I cannot declare it "not null" or "primary key" at this point ALTER TABLE channels add paramname VARCHAR(40) CHARACTER SET ISO8859_1 //5-Populate it with the original data UPDATE channels set paramname=temp_paramname //6-Now make it primary key - this step fails! alter table channels add primary key (paramname) //7-delete the temp column now... I'd be grateful for any help.

Thanks a lot Remy, this works indeed! But I needed to perform a commit after each step, else it threw an error.

Thanks Remy, I'll give it a try and keey you updated!

Hi Dany, the error message said that FB couldn't create the primary key because the column wasn't declared as "not null". Which I couldn't do, because the new column contains nulls right after creation in step 4. I did the steps one by one in FlameRobin, but when everything works I must re-code it either in Delphi or in InnoSetup (because I have to distribute it as part of a software update).

Downloading Android SDK through Getit seems to work now!

Hello all, Delphi supports 64-bit development since XE2. But somehow it is still not possible to list and import 64-bit type libraries ???? Kind regards, Arthur

Hi David, I'm aware of these workarounds, thanks. But I'm also aware that a 32 bit process *can* actually see the 64 bit registry, see https://docs.microsoft.com/en-us/windows/win32/winprog64/accessing-an-alternate-registry-view . And if that weren't the case, the problem could also be solved by putting the tlb importer GUI in a separate process, to be compiled in two versions. It would just be really nice if this feature worked like it's supposed to.

The reason one pays for a subscription is for the product to be up to date. 64 bit support was hailed 7 years ago so I guess it's not unreasonable to expect it to work by now.

So? The IDE could spawn a 64 bit helper process to retrieve the info.

Using Wireshark, I can observe how the Delphi IDE queries the DNS for "getit.embarcadero.com" as soon as Delphi tries to install the Android platform. This tells me that the IDE really uses Getit as the mechanism to retrieve the Android SDK. Anyway, the DNS server answers with the IP "204.216.225.162". Then Delphi initiates a TCP connection to that address on port 443. The connection is successful and a TLS connection is initiated. The server exists and is listening! A few seconds later, the error message "cannot load data from the server. Please, check your connection status" appears in Delphi. So... Even though Getit basically works, it seems that the Android SDK is AWOL on the server itself. I had installed Delphi from the ISO because I wanted to avoid dependencies on unreliable external sources. An ISO/DVD is supposed to have a self-contained installer with the correct versions of the dependencies, but the person who composed this ISO really didn't think things through well enough. You know, one reason for archiving an ISO is to be able to install the product exactly how it was at the time of the release. That isn't possible if external dependencies are missing or have changed in the mean time.

No. GetIt itself does work now and shows me lots of libraries, but Delphi 10.3.2 Rio is unable to automatically download/install the Android SDK. If anyone buys & Installs Delphi now (from the iso) with the intention of developing for Android, he'll be disappointed. Regards,Arthur

I recently had the case that an update of a third party library "patched" a VCL routine and replaced it with a different one for speed reasons, only the new routine turned out to be buggy. This caused a program of mine to suddenly behave erratically. It took me and the author of the library quite some time to figure it out...

My Delphi 10.3.2 IDE is still unable to retrieve the Android SDK. It throws the error "Cannot load data from the server. Please check your connection status" when I try to build an Android app. Both with the original settings and the alternative ones.

Just an idea how you can quickly find out which of your units is broken: Units normally get initialized in the same sequence in which they are entered in the *.dpr file. So... my idea is to create a new empty "diagnostic" unit. Let it use only the "windows" unit and nothing else. For the rest, keep the interface section empty. In the implementation section of this unit, write an initialization that simply shows a "hello world" messagebox. This initialization will only execute if none of the units that initialized before it caused the program to terminate. So... Just start playing with the position of this unit in the USES clause of the DPR file. For starters, place it somewhere in the middle. Compile, and see if the messagebox appears. If yes, move the unit halfway further down in the USES clause. If not, move it halfway further up. See, we're doing a binary search here... Repeat this process until you have found the exact position where the messagebox no longer appears. It shouldn't take more than a dozen attempts. The offending unit will be the one right before the diagnostic unit. It's either that unit itself, or some unit which it depends on and which isn't in the uses clause.

Hello World, Can anyone please point me to some instructions on how to manually install the Android SDK in such a way that it'll work with Delphi Rio (in a VM)? I just can't understand how Embarcadero didn't have a contingency plan for keeping GetIt online. A two-weeks outage is soooooo unacceptable. Regards, Arthur

... And it's down again. Sigh. The Quality of the Portal needs improving.

Yes, suddenly works now. No captcha in sight.

Like I said, I do test my apps on Windows 10 (using remote debugging, on a system with 3 monitors). But I do the compilation inside a Windows 7 VM, on a stable system that doesn't change all the time.

The web site responds "Sorry, an error occurred trying to log you in - please try again." (and I see no captcha).

YES I can, but it takes a whole minute to respond.

It doesn't feel right for me to develop under an operating system that's constantly changing. It happened 3 times to me in the past 12 months that a Windows update broke something serious on my Windows 10 system. I feel much safer developing inside a Windows 7 x64 VM. To test under Windows 10, I use remote debugging.

The IDE which you use to edit the project and the compiler which you use to build & deliver need not be the same... I use FinalBuilder for my builds so I can specify which compiler to use. So I can edit in one Delphi version and build using another. Often, if I migrate a project to a newer Delphi version, I want to avoid breaking things. So I keep editing using the old IDE until it compiles without warnings in both compiler versions. This way the conversion can be a gradual process and I can still publish new releases and bugfixes if the conversion isn't ready yet. And sometimes it is useful to deliberately use an older compiler in the build process if it produces much smaller compiled code. The difference between Delphi 2009 and Rio is quite dramatic. Now I know that this doesn't make much sense in single-executable projects but it does have an impact if the project contains two dozen DLL's that suddenly triple in size.

If I were you I'd hang on to that D2009 version for a while, at least if the size of your executables and DLL's matters. D2009 produces much more compact executables/DLL's than all later versions.

No!