Search Results

Search found 23 results on 1 pages for 'mjustin'.

Page 1/1 | 1 

  • Does UNC work between two Intranet domains?

    - by mjustin
    We have some servers which will move to a new Windows 2008 domain, and some Windows 2000 servers which I would prefer to keep in their current domain for a while (until we have the resources to test and reinstall them as Windows 2008 systems in the new domain too). Can UNC still be used to connect to file server resources on the new system from the old servers? Or is UNC limited to work only within one domain? I'll do tests on Monday but every feedback would be very welcome.

    Read the article

  • One vs. many domain user accounts in a server farm

    - by mjustin
    We are in a migration process of a group of related computers (Intranet servers, SQL, application servers of one application) to a new domain. In the past we used one domain user account for every computer (web1, web2, appserver1, appserver2, sql1, sqlbackup ...) to access central Windows resources like network shares. Every computer also has a local user account with the same name. I am not sure if this is necessary, or if it would be easier to configure and maintain to use one domain user account. Are there key advantages / disadvantages of having one single user account vs. dedicated accounts per computer for this group of background servers? If I am not wrong, one advantage besides easier administration of the user account could be that moving installed applications and services around between the computers does not require a check of the access rights anymore. (Except where IP addresses or ports are used)

    Read the article

  • Text template or tool for documentation of computer configurations

    - by mjustin
    I regularly write and update technical documentation which will be used to set up a new virtual machine, or to have a lookup for system dependencies in networks with around 20-50 (server-side) computers. At the moment I use OpenOffice Writer with text tables, and create one document per intranet domain. To improve this documentation, I would like to collect some examples to identify areas where my documents can be improved, regarding general structure and content, to make it easy to read and use not only for me but also for technical staff, helpdesk etc. Are there simple text templates (for example for OpenOffice Writer) or tools (maybe database-driven) for structured documentation of a computer configuration? Such a template / tool should provide required and optional configuration sections, like 'operating system', 'installed services', 'mapped network drives', 'scheduled tasks', 'remote servers', 'logon user account', 'firewall settings', 'hard disk size' ... It is not so much low-level hardware docs but more infrastructure / integration information in these documents (no BIOS settings, MAC addresses).

    Read the article

  • Amazon Elastic Compute Cloud: how to set up a small and persistent test machine?

    - by mjustin
    Hello, is there a short tutorial available which shows how I can set up a small Linux server on Amazon EC2 so that I can configure it and launch it when needed? I understand that there is EBS to provide a persistent storage and that an image can be booted right from EBS. There are also existing images which are perfect starting points, with Linux installed, so I simply have to 'copy' somehow an existing image to EBS, and configure it there. Is there some article which guides through these steps?

    Read the article

  • Is it possible to tweak TStringField to work like TWideStringField in Delphi?

    - by mjustin
    We want to use Unicode with Delphi 2009 and Interbase, and found that to switch the character encoding from WIN1252 to UNICODE_FSS we first have to replace all instances of TStringField with TWideStringField in all datamodules. For around 60 datamodules, we can not simply do this over one weekend. I can see only two options for a migration strategy: find a workaround which allows to use the existing TStringField fields without triggering the 'expected: TWideStringField' error or remove all persistent fields to avoid the string type conflict As far as I know the field types for persistent database fields are registered in some kind of class registry. Could we use this to make Delphi believe that a TStringField is ok for a Interbase character column with UNICODE_FSS encoding? Or can we use a commercial dbExpress driver which work with TStringField in both cases? See also my related question: http://stackoverflow.com/questions/2302670/delphi-dbexpress-and-interbase-unicode-migration-steps-and-risks

    Read the article

  • Why is Self assignable in Delphi?

    - by mjustin
    This code in a GUI application compiles and runs: procedure TForm1.Button1Click(Sender: TObject); begin Self := TForm1.Create(Owner); end; (tested with Delphi 6 and 2009) why is Self writeable and not read-only? in which situations could this be useful? Edit: is this also possible in Delphi Prism? (I think yes it is, see here) Update: Delphi applications/libraries which make use of Self assignment: python4delphi

    Read the article

  • Delphi dbExpress and Interbase: Unicode migration steps and risks?

    - by mjustin
    Currently, our database uses Win1252 as the only character encoding. We will have to support Unicode in the database tables soon, which means we have to perform this migration for four databases and around 80 Delphi applications which run in-house in a 24/7 environment. Are there recommendations for database migrations to UTF-8 (or UNICODE_FSS) for Delphi applications? Some questions listed below. Many thanks in advance for your answers! are there tools which help with the migration of the existing databases (sizes between 250 MB and 2 GB, no Blob fields), by dumping the data, recreating the database with UNICODE_FSS or UTF-8, and loading the data back? are there known problems with Delphi 2009, dbExpress and Interbase 7.5 related to Unicode character sets? would you recommend to upgrade the databases to Interbase 2009 first? (This upgrade is planned but does not have a high priority) can we simply migrate the database and Delphi will handle the Unicode character sets automatically, or will we have to change all character field types in every Datamodule (dfm and source code) too? which strategy would you recommend to work on the migration in parallel with the normal development and maintenance of the existing application? The application runs in-house so development and database administration is done internally. Update: one problem I found now is that there are two different persistent field types for Unicode and non Unicode character fields. For the existing database, dbExpress creates TStringField objects. For the Unicode database fields, dbExpress creates (or expects!) TWideStringField objects. So we can not just change the database and the connection code page to Unicode. We also have to modify all datamodules to use the new field type. The modified datamodule however will not be backwards compatible.

    Read the article

  • How can a Delphi TForm / TPersistent object calculate its own deserialization time?

    - by mjustin
    For performance tests I need a way to measure the time needed for a form to load its definition from the DFM. All existing forms inherit a custom form class. To capture the current time, this base class needs overriden methods as "extension points": start of the deserialization process after the deserialization (can be implemented by overriding the Loaded procedure) the moment just before the execution of the OnFormCreate event So the log for TMyForm.Create(nil) could look like: - 00.000 instance created - 00.010 before deserialization - 01.823 after deserialization - 02.340 before OnFormCreate Which TObject (or TComponent) methods are best suited? Maybe there are other extension points in the form creation process, please feel free to make suggestions.

    Read the article

  • How can a Delphi TForm / TPersistent object calculate its own construction and deserialization time?

    - by mjustin
    For performance tests I need a way to measure the time needed for a form to load its definition from the DFM. All existing forms inherit a custom form class. To capture the current time, this base class needs overriden methods as "extension points": start of the deserialization process after the deserialization (can be implemented by overriding the Loaded procedure) the moment just before the execution of the OnFormCreate event So the log for TMyForm.Create(nil) could look like: - 00.000 instance created - 00.010 before deserialization - 01.823 after deserialization - 02.340 before OnFormCreate Which TObject (or TComponent) methods are best suited? Maybe there are other extension points in the form creation process, please feel free to make suggestions. Background: for some of our app forms which have a very basic structure (with some PageControls and QuantumGrids) I realized that it is not database access and other stuff in OnFormShow but the construction which took most of the time (around 2 seconds) which makes me wonder where this time is spent. As a reference object I will also build a mock form which has a similar structure but no code or datamodule connections and measure its creation time.

    Read the article

  • Delphi 2009 dbExpress and Interbase: Unicode migration steps and risks?

    - by mjustin
    Currently, our database uses Win1252 as the only character encoding. We will have to support Unicode in the database tables soon, which means we have to perform this migration for four databases and around 80 Delphi applications which run in-house in a 24/7 environment. Are there recommendations for database migrations to UTF-8 (or UNICODE_FSS) for Delphi applications? Some questions listed below. Many thanks in advance for your answers! are there tools which help with the migration of the existing databases (sizes between 250 MB and 2 GB, no Blob fields), by dumping the data, recreating the database with UNICODE_FSS or UTF-8, and loading the data back? are there known problems with Delphi 2009, dbExpress and Interbase 7.5 related to Unicode character sets? would you recommend to upgrade the databases to Interbase 2009 first? (This upgrade is planned but does not have a high priority) can we simply migrate the database and Delphi will handle the Unicode character sets automatically, or will we have to change all character field types in every Datamodule (dfm and source code) too? which strategy would you recommend to work on the migration in parallel with the normal development and maintenance of the existing application? The application runs in-house so development and database administration is done internally. Update: one problem I found now is that there are two different persistent field types for Unicode and non Unicode character fields. For the existing database, dbExpress creates TStringField objects. For the Unicode database fields, dbExpress creates (or expects!) TWideStringField objects. This looks like a lot of work lies ahead. While we could try to avoid persistent fields (and add calculated fields at run time), Of course we would prefer a solution which does not require so many changes in existing units and DFM files.

    Read the article

  • Delphi dbExpress and Interbase: UTF8 migration steps and risks?

    - by mjustin
    Currently, our database uses Win1252 as the only character encoding. We will have to support Unicode in the database tables soon, which means we have to perform this migration for four databases and around 80 Delphi applications which run in-house in a 24/7 environment. Are there recommendations for database migrations to UTF-8 (or UNICODE_FSS) for Delphi applications? Some questions listed below. Many thanks in advance for your answers! are there tools which help with the migration of the existing databases (sizes between 250 MB and 2 GB, no Blob fields), by dumping the data, recreating the database with UNICODE_FSS or UTF-8, and loading the data back? are there known problems with Delphi 2009, dbExpress and Interbase 7.5 related to Unicode character sets? would you recommend to upgrade the databases to Interbase 2009 first? (This upgrade is planned but does not have a high priority) can we simply migrate the database and Delphi will handle the Unicode character sets automatically, or will we have to change all character field types in every Datamodule (dfm and source code) too? which strategy would you recommend to work on the migration in parallel with the normal development and maintenance of the existing application? The application runs in-house so development and database administration is done internally.

    Read the article

  • How can I dynamically inject code to event handlers in Delphi?

    - by mjustin
    For debugging / performance tests I would like to dynamically add logging code to all event handlers of components of a given type. For example, for all Dataset components located ona TDatamodule, I would like to add some code for the BeforeOpen and the AfterOpen event to store the start and end time and send a line to a logger with the elapsed time in the AfterOpen event. I would prefer to do this dynamically (no component subclassing), so that I can add this to all existing datamodules and forms with minimal effort only when needed. Iterating all components and filtering by their type is easy, but for the components which already have event handlers assigned, I need a way to store the existing event handlers, and assign a new modified event handler which first does the logging and then will invoke the original code which was already present. Is there a design pattern which can be applied, or even some example code which shows how to implement this in Delphi?

    Read the article

  • How can I dynamically inject code into event handlers in Delphi?

    - by mjustin
    For debugging / performance tests I would like to dynamically add logging code to all event handlers of components of a given type. For example, for all Dataset components located ona TDatamodule, I would like to add some code for the BeforeOpen and the AfterOpen event to store the start and end time and send a line to a logger with the elapsed time in the AfterOpen event. I would prefer to do this dynamically (no component subclassing), so that I can add this to all existing datamodules and forms with minimal effort only when needed. Iterating all components and filtering by their type is easy, but for the components which already have event handlers assigned, I need a way to store the existing event handlers, and assign a new modified event handler which first does the logging and then will invoke the original code which was already present. Is there a design pattern which can be applied, or even some example code which shows how to implement this in Delphi?

    Read the article

  • How can I measure TForm deserialization time in Delphi?

    - by mjustin
    For performance tests I need a way to measure the time needed for a form to load its definition from the DFM. All existing forms inherit a custom form class. To capture the current time, this base class needs overriden methods as "extension points": before the beginning of the deserialization process after the completion of deserialization (can be implemented by overriding the Loaded procedure) the moment just before the execution of the OnFormCreate event Which TObject (or TComponent) methods are best suited? Maybe there are other extension points in the form creation process, please feel free to make suggestions.

    Read the article

  • How can a Delphi TPersistent object calculate its own deserialization time?

    - by mjustin
    For performance tests I need a way to measure the time needed for a form to load its definition from the DFM. All existing forms inherit a custom form class. To capture the current time, this base class needs overriden methods as "extension points": start of the deserialization process after the deserialization (can be implemented by overriding the Loaded procedure) the moment just before the execution of the OnFormCreate event So the log for TMyForm.Create(nil) could look like: - 00.000 instance created - 00.010 before deserialization - 01.823 after deserialization - 02.340 before OnFormCreate Which TObject (or TComponent) methods are best suited? Maybe there are other extension points in the form creation process, please feel free to make suggestions.

    Read the article

  • Where can I find "reference barcodes" to verify barcode library output?

    - by mjustin
    This question is not about 'best' barcode library recommendation, we use various products on different platforms, and need a simple way to verify if a given barcode is correct (according to its specification). There are some free online bar code generators in the Internet, and I found many differences between their output and our library output regarding graphics and text field below the code. Now I am not sure which one is wrong, and before filing bug report I want to make sure how the correct barcode should look like. We mainly need Code128 and UCC/EAN-128 with A/B/C subcodes. Which resource would you suggest?

    Read the article

  • String Field Sizes for unicode database fields using different data access components

    - by Serg
    mjustin in his question 1 and question 2 says that TWideStringField.Size property for UTF8 fields in Delphi 2009 dbExpress is 4 times larger than the logical field size (max number of characters in the field). I inclined to consider this a dbExpress bug. That is what Delphi 2009 Help says: The interpretation of Size depends on the data type. The meaning of Size for data types that use it is given in the following table. For all other data types, Size is not used and its value is always 0. ftString - Size is the maximum number of characters in the string. I am using FibPlus 6.9.9 and it follows the above documentation - the string field size is the maximum number of characters, not bytes. So the question also implies the following question: Are DbExpress drivers in Delphi 2009 unusable for unicode databases?

    Read the article

1