"Object reference not set to an instance of an object" when loading a SQL Server view into the project

latolap · August 28, 2026, 7:42am

When I try to load some views in the Database pane, PHPMaker shows "Object reference not set to an instance of an object" and the view cannot be added to the project. After systematic testing, the SQL constructs are irrelevant: the only discriminator is the length of the view definition — anything over 4000 characters fails.

Minimal reproduction — two views identical except for a padding comment:

CREATE VIEW dbo.TestShort AS
/* comment of ~3400 'x' characters */
SELECT id, name FROM dbo.users;
-- total definition length 3539 chars -> loads fine

CREATE VIEW dbo.TestLong AS
/* comment of ~4500 'x' characters */
SELECT id, name FROM dbo.users;
-- total definition length 4574 chars -> "Object reference not set to an instance of an object"

I also verified with short probe views that CTEs (WITH), derived tables, OUTER APPLY, UNION ALL, FORMAT(), cross-database three-part names and aggregations all load fine individually — as long as the definition stays under 4000 characters. Across all the real views the failing ones are exactly those with LEN(definition) > 4000 (e.g. 4320 and 7309 chars), while everything up to ~3300 loads.

Workaround I currently use: wrap each long view in a Custom View defined as SELECT * FROM dbo.TheLongView — the short wrapper always loads.

DGarza · September 1, 2026, 6:15pm

I am currently testing the migration of a project from PHPMaker 2025 to PHPMaker 2026.13.0, using SQL Server, and I have encountered what appears to be an issue with the synchronization/loading of a specific SQL Server View.

The View is called dbo.Ticket_Cerrados and works correctly in the PHPMaker 2025 project.

When I open a copy of the PHPMaker 2025 project for the first time with PHPMaker 2026, PHPMaker detects that the database has changed and displays:

Database changed – Do you want to keep old definition or update to new definition?

If I select Keep, Ticket_Cerrados remains in the project and PHPMaker 2026 shows its ID field as the Primary Key.

However, if I select Update, PHPMaker removes all fields from Ticket_Cerrados. The synchronization log shows:

#Ticket_Cerrados
#
DELETED : (Field) Ticket_Cerrados->AgenteAsignado
DELETED : (Field) Ticket_Cerrados->Date_Created
DELETED : (Field) Ticket_Cerrados->Date_Done
DELETED : (Field) Ticket_Cerrados->Departamento
DELETED : (Field) Ticket_Cerrados->Descripcion
DELETED : (Field) Ticket_Cerrados->Descripcion_Agente
DELETED : (Field) Ticket_Cerrados->FotoLogin
DELETED : (Field) Ticket_Cerrados->ID
DELETED : (Field) Ticket_Cerrados->Imagen
DELETED : (Field) Ticket_Cerrados->ImagenSize
DELETED : (Field) Ticket_Cerrados->ImagenType
DELETED : (Field) Ticket_Cerrados->Nombre
DELETED : (Field) Ticket_Cerrados->Prioridad
DELETED : (Field) Ticket_Cerrados->Status
DELETED : (Field) Ticket_Cerrados->Tipo_Incidente
DELETED : (Field) Ticket_Cerrados->Titulo
DELETED : (Field) Ticket_Cerrados->UsuarioID

The SQL Server View itself still exists in the database and works correctly.

To determine whether the problem was related to the old PHPMaker project metadata, I created a new View called dbo.Ticket_Cerrados_Prueba, using essentially the same SQL definition as Ticket_Cerrados.

PHPMaker correctly detected the new View during synchronization:

#Ticket_Cerrados_Prueba
#
ADDED : (VIEW) Ticket_Cerrados_Prueba

However, after enabling/selecting the new View in the PHPMaker project, PHPMaker displays the following error:

Object reference not set to an instance of an object.

After this error, attempting to open Ticket_Cerrados_Prueba causes the same error again, and PHPMaker may become unusable/close, requiring me to restart PHPMaker.

I also performed several tests to isolate the issue.

The View definition is not unusually large:

Ticket_Cerrados          LEN: 1127
Ticket_Cerrados_Prueba   LEN: 1093
Tickets_Abiertos         LEN: 1150

I also have another existing View called dbo.Tickets_Abiertos with a very similar structure. It also uses a RIGHT OUTER JOIN, its ID column is also reported by SQL Server as nullable, and PHPMaker 2026 loads and synchronizes this View successfully.

During synchronization, for example, PHPMaker reports:

#Tickets_Abiertos
#
CHANGED : (Field) Tickets_Abiertos->ID - AutoIncrement (False to True), Attribute (36 to 32)

Therefore, the issue does not appear to be caused simply by the RIGHT OUTER JOIN, the nullable ID, or the length of the View definition.

As an additional test, I created a very simple View:

CREATE VIEW dbo.Ticket_Cerrados_Test_Min
AS
SELECT
    dbo.Ticket.ID,
    dbo.Ticket.Titulo
FROM dbo.Ticket
WHERE dbo.Ticket.FKStatus = '3';

PHPMaker 2026 detects, enables and opens this minimal View correctly without any errors.

Therefore, the issue appears to occur when PHPMaker 2026 parses/loads the metadata of the complete Ticket_Cerrados View.

For reference, this is the original View definition:

CREATE VIEW dbo.Ticket_Cerrados
AS
SELECT
    dbo.Ticket.ID,
    dbo.Ticket.Titulo,
    dbo.Departamento.Nombre AS Departamento,
    dbo.Ticket.Descripcion,
    dbo.Status.Nombre AS Status,
    dbo.Prioridad.Nombre AS Prioridad,
    dbo.Ticket.Imagen,
    dbo.Ticket.ImagenType,
    dbo.Ticket.ImagenSize,
    dbo.Ticket.Date_Created,
    dbo.Ticket.Date_Done,
    dbo.Agente.Nombre AS AgenteAsignado,
    dbo.Ticket.Descripcion_Agente,
    dbo.Ticket.FKUser AS UsuarioID,
    dbo.Tipo_Incidente.Nombre AS Tipo_Incidente,
    dbo.Users.Nombre,
    dbo.Users.FotoLogin
FROM dbo.Ticket
RIGHT OUTER JOIN dbo.Users
    ON dbo.Ticket.FKUser = dbo.Users.ID
INNER JOIN dbo.Departamento
    ON dbo.Users.FKDepartamento = dbo.Departamento.ID
INNER JOIN dbo.Status
    ON dbo.Ticket.FKStatus = dbo.Status.ID
INNER JOIN dbo.Prioridad
    ON dbo.Ticket.FKPrioridad = dbo.Prioridad.ID
INNER JOIN dbo.Agente
    ON dbo.Ticket.FKAgente = dbo.Agente.ID
INNER JOIN dbo.Tipo_Incidente
    ON dbo.Ticket.FKIncidente = dbo.Tipo_Incidente.ID
WHERE dbo.Ticket.FKStatus = '3';

Environment:

PHPMaker 2026.13.0
Project migrated from PHPMaker 2025
Microsoft SQL Server
The problem is reproducible with a copy of the original PHPMaker 2025 project.

Could you please confirm whether this is a known issue in PHPMaker 2026, or if there is a specific part of this View definition that PHPMaker 2026 cannot currently parse?

I am particularly concerned because I have other, considerably larger PHPMaker 2025 projects that need to be migrated to PHPMaker 2026, and I would like to determine whether Views may be lost or become unusable during synchronization.

I can provide the project or additional database/View information if needed to reproduce the issue.

Thank you.

Webmaster · September 2, 2026, 4:39am

Try v2026.14.

DGarza · September 2, 2026, 2:50pm

Tested again with PHPMaker 2026.14.0 using a fresh PHPMaker 2025 project file.
During the initial database synchronization, choosing Update still marks every field of Ticket_Cerrados as DELETED.
Tickets_Abiertos and the other SQL Server views synchronize normally.
Therefore the issue is still reproducible in 2026.14 and is not resolved by the “Loading SQL Server View with 4000+ characters comments” fix.

MichaelG · September 3, 2026, 1:00am

Please also show the table schema for the related tables (i.e. Tickets, Departmento, etc...) used in the View for testing.

DGarza · September 3, 2026, 3:05am

-- ============================================================
-- PHPMaker 2026.14 - Reproduction schema for Ticket_Cerrados
-- Database: HELPDESK
-- Related tables + view definition
-- ============================================================

USE [HELPDESK]
GO

SET ANSI_NULLS ON
GO

SET QUOTED_IDENTIFIER ON
GO

-- TABLE: Departamento
CREATE TABLE [dbo].[Departamento](
[ID] [int] IDENTITY(1,1) NOT NULL,
[Nombre] varchar NOT NULL,
PRIMARY KEY CLUSTERED ([ID] ASC)
) ON [PRIMARY]|
GO

-- TABLE: Status
CREATE TABLE [dbo].[Status](
[ID] [int] IDENTITY(1,1) NOT NULL,
[Nombre] varchar NOT NULL,
PRIMARY KEY CLUSTERED ([ID] ASC)
) ON [PRIMARY]
GO

-- TABLE: Prioridad
CREATE TABLE [dbo].[Prioridad](
[ID] [int] IDENTITY(1,1) NOT NULL,
[Nombre] varchar NOT NULL,
PRIMARY KEY CLUSTERED ([ID] ASC)
) ON [PRIMARY]
GO

-- TABLE: Agente
CREATE TABLE [dbo].[Agente](
[ID] [int] IDENTITY(1,1) NOT NULL,
[Nombre] varchar NOT NULL,
PRIMARY KEY CLUSTERED ([ID] ASC)
) ON [PRIMARY]
GO

-- TABLE: Tipo_Incidente
CREATE TABLE [dbo].[Tipo_Incidente](
[ID] [int] IDENTITY(1,1) NOT NULL,
[Nombre] varchar NOT NULL,
PRIMARY KEY CLUSTERED ([ID] ASC)
) ON [PRIMARY]
GO

-- TABLE: Users
CREATE TABLE [dbo].[Users](
[ID] [int] IDENTITY(1,1) NOT NULL,
[Nombre] varchar NOT NULL,
[Usuario] varchar NOT NULL,
[Constrasena] varchar NOT NULL,
[UserLevel] varchar NOT NULL,
[Activated] [bit] NOT NULL,
[Notes] [text] NULL,
[Exp_date] datetime2 NULL,
[FKDepartamento] [int] NULL,
[MessengerColor] nvarchar NULL,
[CreatedAt] [datetime] NULL,
[FotoLogin] varbinary NULL,
[FechaNacimiento] [date] NULL,
CONSTRAINT [PK__Users__3214EC273A51553F] PRIMARY KEY CLUSTERED ([ID] ASC),
CONSTRAINT [UQ_Usuario] UNIQUE NONCLUSTERED ([Usuario] ASC)
) ON [PRIMARY] TEXTIMAGE_ON [PRIMARY]
GO

ALTER TABLE [dbo].[Users] WITH CHECK ADD CONSTRAINT [FK__Users__FKDeparta__619B8048]
FOREIGN KEY([FKDepartamento]) REFERENCES [dbo].[Departamento] ([ID])
GO

ALTER TABLE [dbo].[Users] CHECK CONSTRAINT [FK__Users__FKDeparta__619B8048]
GO

-- TABLE: Ticket
CREATE TABLE [dbo].[Ticket](
[ID] [int] IDENTITY(1,1) NOT NULL,
[Titulo] varchar NOT NULL,
[Descripcion] varchar NOT NULL,
[ImagenSize] [int] NULL,
[ImagenType] varchar NULL,
[Imagen] varbinary NULL,
[ImagenNombre] varchar NULL,
[FKUser] [int] NULL,
[FKAgente] [int] NOT NULL,
[Descripcion_Agente] varchar NULL,
[UsuarioTicket] varchar NULL,
[FKStatus] [int] NULL,
[FKPrioridad] [int] NULL,
[FKIncidente] [int] NULL,
[FirmaTouchScreen] varchar NULL,
[Date_Created] datetime2 NULL,
[Date_Done] datetime2 NULL,
CONSTRAINT [PK__Ticket__3214EC271902DE8E] PRIMARY KEY CLUSTERED ([ID] ASC)
) ON [PRIMARY] TEXTIMAGE_ON [PRIMARY]
GO

ALTER TABLE [dbo].[Ticket] ADD CONSTRAINT [DF_Ticket_FKAgente] DEFAULT ((3)) FOR [FKAgente]
GO
ALTER TABLE [dbo].[Ticket] ADD CONSTRAINT [DF_Ticket_FKStatus] DEFAULT ((1)) FOR [FKStatus]
GO
ALTER TABLE [dbo].[Ticket] ADD CONSTRAINT [DF_Ticket_Date_Created] DEFAULT (getdate()) FOR [Date_Created]
GO
ALTER TABLE [dbo].[Ticket] ADD CONSTRAINT [DF_Ticket_Date_Done] DEFAULT (getdate()) FOR [Date_Done]
GO

ALTER TABLE [dbo].[Ticket] WITH CHECK ADD CONSTRAINT [FK__Ticket__FKAgente__15502E78]
FOREIGN KEY([FKAgente]) REFERENCES [dbo].[Agente] ([ID])
GO
ALTER TABLE [dbo].[Ticket] CHECK CONSTRAINT [FK__Ticket__FKAgente__15502E78]
GO

ALTER TABLE [dbo].[Ticket] WITH CHECK ADD CONSTRAINT [FK__Ticket__FKPriori__797309D9]
FOREIGN KEY([FKPrioridad]) REFERENCES [dbo].[Status] ([ID])
GO
ALTER TABLE [dbo].[Ticket] CHECK CONSTRAINT [FK__Ticket__FKPriori__797309D9]
GO

ALTER TABLE [dbo].[Ticket] WITH CHECK ADD CONSTRAINT [FK__Ticket__FKStatus__7A672E12]
FOREIGN KEY([FKStatus]) REFERENCES [dbo].[Status] ([ID])
GO
ALTER TABLE [dbo].[Ticket] CHECK CONSTRAINT [FK__Ticket__FKStatus__7A672E12]
GO

ALTER TABLE [dbo].[Ticket] WITH CHECK ADD CONSTRAINT [FK__Ticket__FKUser__145C0A3F]
FOREIGN KEY([FKUser]) REFERENCES [dbo].[Users] ([ID])
GO
ALTER TABLE [dbo].[Ticket] CHECK CONSTRAINT [FK__Ticket__FKUser__145C0A3F]
GO

-- VIEW: Ticket_Cerrados
CREATE VIEW [dbo].[Ticket_Cerrados]
AS
SELECT dbo.Ticket.ID,
dbo.Ticket.Titulo,
dbo.Departamento.Nombre AS Departamento,
dbo.Ticket.Descripcion,
dbo.Status.Nombre AS Status,
dbo.Prioridad.Nombre AS Prioridad,
dbo.Ticket.Imagen,
dbo.Ticket.ImagenType,
dbo.Ticket.ImagenSize,
dbo.Ticket.Date_Created,
dbo.Ticket.Date_Done,
dbo.Agente.Nombre AS AgenteAsignado,
dbo.Ticket.Descripcion_Agente,
dbo.Ticket.FKUser AS UsuarioID,
dbo.Tipo_Incidente.Nombre AS Tipo_Incidente,
dbo.Users.Nombre,
dbo.Users.FotoLogin
FROM dbo.Ticket
RIGHT OUTER JOIN dbo.Users
ON dbo.Ticket.FKUser = dbo.Users.ID
INNER JOIN dbo.Departamento
ON dbo.Users.FKDepartamento = dbo.Departamento.ID
INNER JOIN dbo.Status
ON dbo.Ticket.FKStatus = dbo.Status.ID
INNER JOIN dbo.Prioridad
ON dbo.Ticket.FKPrioridad = dbo.Prioridad.ID
INNER JOIN dbo.Agente
ON dbo.Ticket.FKAgente = dbo.Agente.ID
INNER JOIN dbo.Tipo_Incidente
ON dbo.Ticket.FKIncidente = dbo.Tipo_Incidente.ID
WHERE dbo.Ticket.FKStatus = '3'
GO

I can't add the file

MichaelG · September 3, 2026, 4:36am

Using PHPMaker 2026.14, I have no problem in loading the database View using your database schema.

It may be related to your project. You'd better send your project/database schema to the support email for checking if you are a registered user.

DGarza · September 3, 2026, 5:14am

Thanks. I am a registered user.

Before sending the complete project/database schema to the support email, I am going to perform a few additional tests to try to isolate the cause.

Since Ticket_Cerrados is the only SQL Server View in this project showing this behavior, I will temporarily simplify the View and rebuild it incrementally, adding its fields and JOINs step by step and synchronizing the database after each change.

This should help determine whether a specific field, JOIN, data type, or part of the View definition is triggering the issue.

I also corrected the FKPrioridad foreign key in the Ticket table so that it references Prioridad(ID) instead of Status(ID), but after synchronizing the database the issue with Ticket_Cerrados remains unchanged.

If I cannot identify the cause with these tests, I will send the project and the complete database schema to the support email so you can reproduce it with the actual project structure.

I will post the results here once I finish these tests.

latolap · September 3, 2026, 5:37am

The .pmp file can be opened with Notepad++ or similar editors. You can try closing PHPMaker, making a backup of the .pmp file, opening it in Notepad++, and removing every reference to the Ticket_Cerrados view — they will appear like this:

or other format.

All of them must be deleted, including the part between <Table ... > or <ExtTable ... </ExtTable> (or whatever delimiter PHPMaker uses in your case), and then you can try reloading the project. Make sure to create a backup, because if you delete something incorrectly the project may become corrupted.

DGarza · September 3, 2026, 5:53am

Thanks. I performed several additional tests and I was able to isolate the issue to one specific field: Users.FotoLogin.

I rebuilt the Ticket_Cerrados view incrementally and ran PHPMaker Database Synchronization after each change.

These were the results:

I started with only fields from Ticket. PHPMaker detected all fields correctly as ADDED.
I added Users and Ticket.FKUser = Users.ID. PHPMaker correctly detected only the new fields:
- Nombre
- UsuarioID
I added Departamento. PHPMaker correctly detected:
- Departamento
I added Status. PHPMaker correctly detected:
- Status
I added Prioridad. PHPMaker correctly detected:
- Prioridad
I added Agente. PHPMaker correctly detected:
- AgenteAsignado
I added Tipo_Incidente. PHPMaker correctly detected:
- Tipo_Incidente
I added the remaining non-binary fields (Descripcion_Agente, ImagenSize, ImagenType). PHPMaker correctly detected all three.
I added Ticket.Imagen, which is also a varbinary(max) field. PHPMaker correctly detected:
- Imagen

Up to this point, the view synchronized correctly.

The problem appeared when I added:

dbo.Users.FotoLogin

FotoLogin is a varbinary(max) field.

With the real Users.FotoLogin field included, executing:

SELECT * FROM dbo.Ticket_Cerrados

took approximately 1 minute 34 seconds, and PHPMaker Database Synchronization did not detect FotoLogin as a new field.

I then performed another test, replacing the real field with:

CAST(NULL AS varbinary(max)) AS FotoLogin

With this version:

The same view query took approximately 3 seconds.
PHPMaker immediately detected:

ADDED : (Field) Ticket_Cerrados->FotoLogin

I also measured the actual size of the FotoLogin data. Some individual images are approximately 5.60 MB and 4.97 MB.

Because the same user photo is repeated for every ticket belonging to that user, the 434 rows returned by the view represent approximately:

693,394,358 bytes
661.27 MB
0.65 GB

of repeated FotoLogin binary data alone.

Finally, I removed only Users.FotoLogin from the otherwise complete view.

The query immediately returned to approximately 3 seconds, and PHPMaker Database Synchronization correctly reported only:

DELETED : (Field) Ticket_Cerrados->FotoLogin

Therefore, all the tables, JOINs and other fields synchronize correctly, including Ticket.Imagen (varbinary(max)). The behavior is specifically triggered when the real Users.FotoLogin binary data is included in this view.

This also appears to explain the original behavior where synchronization was unable to correctly detect the fields of Ticket_Cerrados.

I can remove FotoLogin from this view or retrieve the user photo separately, since returning hundreds of MB of repeated image data in the view is clearly inefficient.

However, I wanted to share these test results in case PHPMaker Database Synchronization should still be able to retrieve the view schema/metadata without being affected by the amount of binary data returned by the view.

DGarza · September 3, 2026, 5:53am

I understand that returning this amount of binary image data in the view is inefficient, and I can redesign the view to avoid that.

However, the same view works with PHPMaker 2025, while PHPMaker 2026.14 Database Synchronization fails to correctly detect the view fields when the real Users.FotoLogin data is included.

Since Database Synchronization is primarily reading the database schema/metadata, I would not expect the amount of binary data stored in the field to affect field detection.

Could this be a regression or a change in how PHPMaker 2026 retrieves SQL Server view metadata compared with PHPMaker 2025?

DGarza · September 3, 2026, 5:58am

I also have another SQL Server view, Tickets_Abiertos, which includes the same Users.FotoLogin field.

That view currently returns only 1 record, and PHPMaker does not show the same synchronization problem with it.

This seems to further indicate that the issue is not simply caused by the FotoLogin field or the varbinary(max) data type itself, but may be related to the amount of binary data returned by the view.

In Ticket_Cerrados, the 434 returned rows represent approximately 661 MB of repeated FotoLogin binary data, while Tickets_Abiertos currently returns only one row.

This difference may explain why the problem is reproducible with Ticket_Cerrados but not with Tickets_Abiertos.

MichaelG · September 3, 2026, 12:47pm

You'd better send your project/database to the support email for checking. Read PHPMaker Support page

DGarza · September 3, 2026, 2:25pm

I send the .bak to support, I hope you can help me.

I explain the tests that I'd like to reproduce.

FYI: For the size of .bak file, I used WeTransfer, so the files will expire on 06 September, 2026.